> -----Original Message----- > From: David Howells [mailto:dhowells@xxxxxxxxxx] > Sent: Thursday, April 09, 2009 2:22 PM > To: Muntz, Daniel > Cc: dhowells@xxxxxxxxxx; Tom Talpey; linux-nfs@xxxxxxxxxxxxxxx > Subject: Re: NFS fscache offline mode? > > Muntz, Daniel <Dan.Muntz@xxxxxxxxxx> 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. The two trivial cases are: discard changes from disconnected mode, or propagate all changes when reconnected. Doing something more intelligent is difficult. If writes are allowed, you still run the risk of evicting something you really wanted in the cache (oops, forgot to pin my .bashrc), or getting unexpected disk-full errors. But, you still have something potentially useful if you just make the cache ro when disconnected. > > > 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, You've captured the data and metadata. I suppose there might be some fs-specific hooks needed (e.g., something needed to prevent the nfs client from thinking the server is down). IMHO, it would be really handy if a canonical list of such hooks could be made, and FS-Cache could handle these similar to how export ops work in NFS--the fs supplies routines that FS-Cache calls to make disconnected operation work. > > (2) pulling files into the cache in preparation, Some trivial fs-agnostic ways to do this: use the system before disconnecting, or run a process to walk through the fs catting files that you want in disconnected mode (pulling them into the cache). Just out of curiosity, could one 'tar' up the cache on one machine and drop it on another and have it work? There must be enough state on disk so that a reboot doesn't invalidate your cache, so I'm guessing this might be another way to warm your cache. > > (3) handling requests from userspace that can't be satisfied > when offline, What did you have in mind? > and > > (4) resolving conflicts afterwards. If you stick to the ro case, or the two simple conflict resolution schemes, then this is not an issue. > > 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. That's what 'sed' is for :-) > > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html