Summary: | sysutils/fuse-ntfs triggers a cache inconsistency kernel error message | ||
---|---|---|---|
Product: | Ports & Packages | Reporter: | Bertrand Petit <bsdpr> |
Component: | Individual Port(s) | Assignee: | freebsd-ports-bugs (Nobody) <ports-bugs> |
Status: | Open --- | ||
Severity: | Affects Only Me | CC: | asomers, bsdpr, grahamperrin, kern, lwhsu, rhurlin |
Priority: | --- | ||
Version: | Latest | ||
Hardware: | Any | ||
OS: | Any |
Description
Bertrand Petit
2020-05-19 19:15:06 UTC
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. Also: Buggy fuse server detected · Issue #390 · moosefs/moosefs <https://github.com/moosefs/moosefs/issues/390> |