Bug 246577 - sysutils/fuse-ntfs triggers a cache inconsistency kernel error message
Summary: sysutils/fuse-ntfs triggers a cache inconsistency kernel error message
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
Depends on:
Reported: 2020-05-19 19:15 UTC by Bertrand Petit
Modified: 2020-07-02 04:39 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Petit 2020-05-19 19:15:06 UTC
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?
Comment 1 Li-Wen Hsu freebsd_committer 2020-06-16 11:17:46 UTC
asomers: could you help check if this is a fusefs issue?
Comment 2 Alan Somers freebsd_committer 2020-06-16 13:35:29 UTC
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.
Comment 3 Bertrand Petit 2020-06-16 15:11:26 UTC
Is there something I could to to definitely detect which of the two parts is the trouble source?
Comment 4 Alan Somers freebsd_committer 2020-06-16 15:29:21 UTC
(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.
Comment 5 Bertrand Petit 2020-06-25 02:26:57 UTC
(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.