From: Steve Dickson <SteveD@redhat.com>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Andrew Morton <akpm@osdl.org>,
linux-fsdevel@vger.kernel.org, linux-cachefs@redhat.com
Subject: [PATCH][RFC] NFS: Adding hooks to enable the use of FS-Cache
Date: Fri, 21 Apr 2006 11:14:41 -0400 [thread overview]
Message-ID: <4448F6E1.2060907@RedHat.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2415 bytes --]
This patch (based on Trond's nfs-2.6 git tree) adds the hooks need to
allow NFS to use the generic filesystem caching facility FS-Cache.
Caching is done on a per mount bases. To activate caching, the 'fsc'
flag is need as a mount option.
Ex:
mount -o fsc server:/export /mnt
(binary and source rpms as well as the actual patch are available at
http://people.redhat.com/steved/cachefs/util-linux/)
NFS uses the cache on a readonly bases; Meaning only reads are caches
not writes. But this *does not* mean filesystems have to be mounted
read only. Filesystems are mounted read/write but only data from
reads will be cached. When a file is opened with either RW or WR
bits, the caching will be turned off (see nfs_open for the details).
The reason for read only is became quite apparent that keeping the cache
coherent while jugging both reads and writes is pretty hard. So it was
decided to start with a read only implementation and then move on to a
read/write implementation in the future...
There are still a few rough spots in this patch. One being the
sysctl variables that show what, if any, caching is being done need
to be rolled into NFS I/O metrics code that recently went in.
The second one being, what David termed as, NFS aliasing. The way
NFS manages its super blocks would cause double caching since the
cookies returned by the cache would not be unique. We got around
this problem by making each nfs mount have unique 'fsctag' which
would be used to generate the caching cookie. The default fsctag
value is the mount point but it also can be set on the command line
(which is undocumented at this point since its not clear we really
want to do this).
Unfortunately having the mount command passed the kernel a string turned
out to a bit difficult since NFS used a binary interface (something
that will hopefully change this summer). So David came up with the idea
(not too surprising) of using the keyrings to passed down the string
which did work very well... But as I said, we have every intending of
change the binary interface into an ascii one and when that happens,
this interface will change.
Finally there still needs to be some work on mmapped pages. Its not
clear NFS is used the cache as well as it could when pages are mmapped.
I'm still investigating...
Now I'm sure Trond will find several more rough spots... ;-) but
these are all of the ones I know about....
steved.
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next reply other threads:[~2006-04-21 15:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-21 15:14 Steve Dickson [this message]
2006-04-21 15:31 ` [PATCH][RFC] NFS: Adding hooks to enable the use of FS-Cache Trond Myklebust
2006-04-21 15:42 ` Steve Dickson
2006-04-21 15:53 ` Trond Myklebust
2006-04-21 15:56 ` Steve Dickson
2006-04-21 15:44 ` [Linux-cachefs] " David Howells
-- strict thread matches above, loose matches on Subject: below --
2006-04-21 15:47 Steve Dickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4448F6E1.2060907@RedHat.com \
--to=steved@redhat.com \
--cc=akpm@osdl.org \
--cc=linux-cachefs@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).