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.
> 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?)
> 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!