From: Edwin O. <eo...@mi...> - 2005-05-22 13:38:56
|
I'm toying with implementing a network file system client using FUSE, but I don't know how to keep multiple clients "in sync" with each other as some of them modify the file system. i.e., if machine B modifies a directory, how do I ensure that machine A "sees" the changes? My (perhaps erroneous) understanding is that the kernel caches dentries, and so if A statted the files before B changed them, A wouldn't necessarily stat the files again if the files were still cached. Is this a problem, and if so, what can I do about it? (Is there a way for a FUSE filesystem to invalidate a dentry item asynchronously?) -Ed |
From: Miklos S. <mi...@sz...> - 2005-05-22 14:38:27
|
> I'm toying with implementing a network file system client using FUSE, > but I don't know how to keep multiple clients "in sync" with each other > as some of them modify the file system. > > i.e., if machine B modifies a directory, how do I ensure that machine A > "sees" the changes? Do you want "perfect" synchrony, or is it enough if A catches up after some timeout? > My (perhaps erroneous) understanding is that the kernel caches > dentries, and so if A statted the files before B changed them, A > wouldn't necessarily stat the files again if the files were still > cached. Yes. > Is this a problem, and if so, what can I do about it? (Is there a way > for a FUSE filesystem to invalidate a dentry item asynchronously?) No, there's no way to explicitly invalidate a dentry. However the filesystem can set an arbitrarily small timeout for which the dentry and attributes are cached (this ability is currently not exported through the library API and the timeout is always set to 1 second). Miklos |
From: Edwin O. <eo...@mi...> - 2005-05-22 15:02:22
|
> > >No, there's no way to explicitly invalidate a dentry. However the >filesystem can set an arbitrarily small timeout for which the dentry >and attributes are cached (this ability is currently not exported >through the library API and the timeout is always set to 1 second). > > > If you're saying that a dentry won't ever be cached for more than 1 second, that is adequate for my purposes! It might be nice to have more control in the future, but consider that a wish list item :) -Ed |
From: Adam M. <me...@cs...> - 2005-06-11 18:35:21
|
This question is basically what makes network file systems "interesting". I'd recommend checking out AFS (openafs.org). IMHO it has the best compromise: if multiple writers open a file, the *last* one to close() the file obliterates everybody else's changes. In other words, changes only become visible to your peers once you close() the file. When people hear about this they usually scream bloody murder, but AFS has been running on very large (4,000+ users at CMU, even more at MIT and Stanford) installations at hundreds of sites for over a decade. Other than databases (BerkeleyDB, MySQL, etc), the weak-consistency simply isn't a problem in practice. It also uses callbacks rather than polling (unlike Samba/CIFS it uses them even for read-only clients), which lets it cache much more aggressively than other filesystems. - a Edwin Olson <eo...@mi...> writes: > I'm toying with implementing a network file system client using FUSE, > but I don't know how to keep multiple clients "in sync" with each > other as some of them modify the file system. > > i.e., if machine B modifies a directory, how do I ensure that machine > A "sees" the changes? My (perhaps erroneous) understanding is that the > kernel caches dentries, and so if A statted the files before B changed > them, A wouldn't necessarily stat the files again if the files were > still cached. > > Is this a problem, and if so, what can I do about it? (Is there a way > for a FUSE filesystem to invalidate a dentry item asynchronously?) > > -Ed > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click -- |