[fuse-devel] Cache invalidation protocol, and ways of avoiding -EIO on filetype change

[Nix <ni...@es...>]

So I'm working on a version-controlled filesystem, using FUSE's
low-level API and PostgreSQL. I've gone to some effort to make the
design conform to POSIX, at least as much as a good networked filesystem
does (not easy, POSIX was never really designed for version-control, but
then it was never designed for networking either, which similarly has
files changing contents without the local VFS doing anything to change
them). There are only a couple of places that I suspect may not work
right.

Now obviously a file with a given iode number can't change to a
different type; I'm handling that (it's easy, since the inode numbers
I'm handing out are fakes valid only until umount() anyway). But if I
roll a bunch of files to a different revision, their contents will
change, and right now I have no way of informing the VFS of that so that
the inode can be ditched from the page cache. (Obviously I can fsync()
the file to get *dirty* blocks from the page cache before rolling: it's
the clean blocks that concern me; they may not be clean anymore but the
VFS can't tell that without help.)

This must've come up before in the area of networked filesystems: a
networked FUSE filesystem has to note that remote nodes have changed
files without the local VFS being involved.

Does FUSE have any way to handle this? Would there be any objection
if I added a callback? Rollbacks happen asynchronously to VFS ops,
but I can see no reason to require that: a sensible lowlevel API
addition might be something really simple, maybe a change to
fuse_reply_err:

int fuse_reply_err(fuse_req_t req, int err, int flags);

where one possible flag is (the #define) FUSE_FORGET_INODE. The idea is
that the fsync() and fsyncdir() methods can say `my job is done; please
forget about this inode, as its contents are now known to be
invalid'. It would obviously be invalid to say this for any inode that
has been open()ed and not release()d yet: only a moron would try to
version-roll an open file and not expect to have caching problems, and
I'm going to block that operation. (Even better would be if I could
invalidate a pile of them all at once in one kernel roundtrip, but that
might be pushing it.)


(oh, and one last question: the inode generation number has to increment
whenever an inum is replaced by an inum with the same number and a
different type, right? And can never go down?)

-- 
`Logic and human nature don't seem to mix very well,
 unfortunately.' --- Velvet Wood