lkml.org 
[lkml]   [2004]   [Oct]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Linux-cachefs] Re: [PATCH] NFS using CacheFS
Date

> > The 'fscache' flag will be coming along with the nfs4 support, since
> > nfs4 mounting code does not have an open (unused) mounting flag....
>
> is such a flag even neccessary?
> The way I see fscache is that its operations will be no-ops anyway if you
> haven't mounted any backing cache.

There are two reasons:

(1) The fscache middle bit builds up a cookie tree even if there are no
backing caches. This means if the cache is added later (NFS root, for
example), the netfs then starts caching immediately without requiring a
remount.

(2) NFS is not currently safe with respect to fscache in the following
situation:

mount warthog:/warthog/x /x
mount warthog:/warthog /y

Because NFS ends up with two superblocks for what is one set of
filehandles. This means it tries to get the same cookies out of fscache
twice, which fscache is ill-equipped to handle.

This also introduces unnecessary (IMNSHO) aliasing in each client of
inodes and pages both.

I have a patch to fix NFS to cope with this by modifying the get_sb()
method to allow the filesystem to override the automatic selection of
super->s_root as the root dentry. However, Al Viro is leery of the patch
for some reason.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.094 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site