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

[Miklos S. <mi...@sz...>]

> 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

FUSE does write-through, so there are never any dirty blocks.  The
fsync() method is only interesting if you do buffering in the
filesystem itself.

> 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.

FUSE already does have this: the keep_cache flag in the OPEN reply.

Unless this is set, invalidate_inode_pages() will be called which will
throw away all cached pages.  The exception is locked pages, these are
ones currenly being read or written.

> 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,

Well, then what's the problem?  Fuse already _does_ throw away the
cache on each open() by default.

> (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?)

Generation is only used by the NFS export code.  The rule is that the
inum:generation pair must be a unique identifier for each "file" for
the filesystem's lifetime.

Inum must be unique for all the currently existing "files", but they
may be reused after a file has been deleted.

A "file" in this case is the object that exist between creation
(open(O_CREAT), mkdir(), mknod(), symlink()) and deletion (no more
links, open files and memory mappings).

Inums and generation can be allocated arbitrary ways (they can go
up/down/whatever, there can be a global generation counter or a local
one for each inum) as long as the above uniqueness rules are observed.

Miklos