On a 12-STABLE system (r360207) running fusefs-libs-2.9.9_1 and fusefs-ntfs-2017.3.23 (UBLIO disabled at compile time), while a large copy operation to an ntfs was running I did a "du -s" on that same filesystem to estimate progression and was rewarded by the following message on console:
kernel: fuse_internal_do_getattr: cache incoherent on /mnt! Buggy FUSE server detected. To prevent data corruption, disable the data cache by mounting with -o direct_io, or as directed otherwise by your FUSE server's documentation
A subsequent du(1) execution produced the same message.
Is this expected or is this a bug? Should I actually be worried about the filesystem integrity?
asomers: could you help check if this is a fusefs issue?
That message normally indicates a bug in the FUSE server (not the kernel). It means that while a file was cached in the kernel, its contents changed on the server. So yes, data corruption is a possibility. The possible workarounds are:
1) Convince the maintainer of fusefs-ntfs to upgrade his program to libfuse3. That uses a newer protocol that allows for safer cacheing.
2) Disable the cache by using -o direct_io on the command line, as the console message suggests.
3) Disable the cache globally by setting vfs.fusefs.data_cache_mode=0. That will affect all mounted file systems using libfuse2.
Is there something I could to to definitely detect which of the two parts is the trouble source?
(In reply to Bertrand Petit from comment #3)
Not without a very detailed analysis of the problem. It's most likely a bug in the FUSE server, not the kernel. Since you said you did "du" while a copy was in progress, the problem might be a thread race in the server, but that's just a guess. To definitively answer the question would require a trace of all FUSE operations during your session.
(In reply to Alan Somers from comment #2)
The "-o direct_io" does indeed prevent the error to be triggered, thank you. Writing performance is now even more atrocious but I can live with that.