Hi FUSE folks,
I'd like to share and discuss an issue of fuse's auto_inval_data feature
in writethrough mode.
auto_inval_data is introduced since v3.6 commit
eed2179efe1aac145bf6d54b925b750976380fa6 ("fuse: invalidate inode
mapping if mtime changes"), which invalidates the page cache
automatically when a changed mtime timestamp is detected. This is used
to help the cache consistency when the fuse file could be modified by
bypass, e.g. the backing file is modified directly through the backing
filesystem (e.g. the backing ext4) rather than fuse mountpoint. For
example, when the file data is modified not through FUSE filesystem, the
mtime of the file will be changed; when the FUSE filesystem is doing a
file operation that relying on the latest attribute, it will update the
file attribute (calling fuse_update_attributes()) and (in some
conditions) send a FUSE_GETATTR to server to refresh the cached
attribute. When the FUSE_GETATTR is replied, fuse client will find that
the latest mtime is different with the one cached in kernel, which is a
hint that the file data has been modified without kernel noticing this.
And then the fuse client will invalidate the whole address space, so
that the following data accessing will re-initiate FUSE_READ request to
fetch latest data from fuse server.
We noticed an interesting phenomenon when auto_inval_data works in
writethrough mode. In writethrough mode, the local cached mtime (in
kernel) is not trusted, instead the fuse server is the only one trusted
to maintain mtime (see commit b36c31ba95f0fe0a03c727300d9c4c54438a5636
("fuse: don't update file times")). Thus a generic write(2) routine in
writethrough mode won't update the local cached mtime in kernel
(inode->i_mtime). When processing FUSE_WRITE requests, the fuse server
will update file's mtime. Assuming there's no modification to the file
from other than the fuse client, a later file access to the fuse file
will found a new mtime (retrieved from fuse server) and auto_inval_data
is triggered.
In above example, the file is modified only from fuse filesystem, but an
*extra* redundant invalidation is always required when doing a read
following a write.
I'm not sure if this is a known issue or not, neither if it's a
deliberate design, or actually we could optimize this (if there's any
good solution to it).
--
Thanks,
Jingbo
