Max Kellermann <mk@xxxxxxxxxx> wrote:
> Did you read this part of my email?:
Sorry, I'm trying to deal with several things at once.
> My theory was that fscache shows a mix of old and new pages after the
> file was modified. Does this make sense?
Okay - that makes a bit more sense.
Could the file have been modified by a third party? If you're using NFS3
there's a problem if two clients can modify a file at the same time. The
second write can mask the first write and the client has no way to detect it.
The problem is inherent to the protocol design. The NFS2 and NFS3 protocols
don't support anything better than {ctime,mtime,filesize} - the change
attribute only becomes available with NFS4.
If an NFS file is opened for writing locally, the cache for it supposed to be
invalidated and remain unused until there are no open file descriptors left
referring to it. This is intended for handling DIO writes, but it should
serve for this also.
The following might be of use in checking if the invalidation happens locally:
echo 1 >/sys/kernel/debug/tracing/events/fscache/fscache_invalidate/enable
And then this can be used to check if it correctly identifies that it has an
obsolete version of the file in the cache when it binds to it:
echo 1 >/sys/kernel/debug/tracing/events/cachefiles/cachefiles_coherency/enable
David
--
Linux-cachefs mailing list
Linux-cachefs@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-cachefs
