From: David Howells <dhowells@redhat.com>
To: "Muntz, Daniel" <Dan.Muntz@netapp.com>
Cc: dhowells@redhat.com, "Tom Talpey" <tmtalpey@gmail.com>,
linux-nfs@vger.kernel.org
Subject: Re: NFS fscache offline mode?
Date: Thu, 09 Apr 2009 22:21:47 +0100 [thread overview]
Message-ID: <11770.1239312107@redhat.com> (raw)
In-Reply-To: <7A24DF798E223B4C9864E8F92E8C93EC029314E5@SACMVEXC1-PRD.hq.netapp.com>
Muntz, Daniel <Dan.Muntz@netapp.com> wrote:
> It's not _so_ tricky for the read-only case, and is quite useful (see
> papers by Huston+Honeyman re: disconnected AFS). For writes, my
> recollection is that you pretty much need human intervention to resolve
> conflicts unless a trivial resolution mechanism is defined.
Oh, I agree that's it's much simpler for read-only, and that there's no
trickiness for files that haven't been modified locally whilst offline; but if
any have, it could then be a problem.
The simplest way is to simply discard local changes upon reconnection if the
backing file has changed. Isn't that what we do anyway when in connected
mode.
> > In any case, offline mode isn't something that FS-Cache itself cares
> > about. It is purely a data store. The network filesystems using it must
> > implement offline mode.
>
> That's a bit flippant. You could just as well say that the "network" file
> system should implement its own disk cache. If you're going to cache under
> the fs, you could also do a lot to hide the disconnected status from the fs,
> once again, not too bad if you're doing read-only.
I disagree. FS-Cache provides or will provide the local storage required to
perform offline operation, the ability to pin data within that storage, and
the ability to tag the stored data with the metadata required; but in my
opinion, the netfs, be it NFS, AFS or CIFS, must do the actual work of:
(1) configuring what must be available for disconnected operation,
(2) pulling files into the cache in preparation,
(3) handling requests from userspace that can't be satisfied when offline,
and
(4) resolving conflicts afterwards.
The netfs knows about the structure of the filesystem; fscache does not. The
user interacts with the netfs, not directly with fscache.
> BTW: could we not use the term "network" file system when discussing
> FS-Cache? You've also mentioned using it for iso9660, so it's not just
> for network file systems.
All my documents, code and emails are laced with the term 'netfs' to mean a
client of FS-Cache.
As I have pointed out in my documentation, whilst iso9660 isn't a network
filesystem, it can be considered in the same group for this topic.
David
next prev parent reply other threads:[~2009-04-09 21:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-09 2:20 NFS fscache offline mode? Tom Talpey
2009-04-09 11:14 ` David Howells
2009-04-09 19:13 ` Muntz, Daniel
2009-04-09 21:21 ` David Howells [this message]
2009-04-09 22:27 ` Muntz, Daniel
2009-04-09 23:05 ` David Howells
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=11770.1239312107@redhat.com \
--to=dhowells@redhat.com \
--cc=Dan.Muntz@netapp.com \
--cc=linux-nfs@vger.kernel.org \
--cc=tmtalpey@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.