|Summary:||[FUSEFS] Race at shutdown and corrupt fusefs systems|
|Component:||kern||Assignee:||freebsd-fs (Nobody) <fs>|
|Status:||Closed Not Enough Information|
|Severity:||Affects Some People||CC:||214748mv, asomers, dpejesh, henry.hu.sh, ota, pi, rmacklem, trasz|
Description rkoberman 2015-05-29 05:50:39 UTC
Created attachment 157242 [details] init script to umount fusefs file systems prior to the termination of the daemon The fuse daemon is required to work with fusefs files systems. If ntfs or exfat systems are mounted and the system is shutdown, it appears that the daemon exists prior to the completion of the unmounting of the file system. This leads to corrupt file systems. I ave seen this with NTFS and exFAT, but it cam likely occur with other fusefs systems. After repeated file systems corruptions I added an init script to unmount any fusefs files between LOGIN and DAEMON. Since I added this script, I have had no corruptions of NTFS systems. (I am no longer using exFAT.) I would suggest either including such a scrip in the base system or fixing the system so that the daemon exists only after any fusefs systems have been unmounted.
Comment 1 Kurt Jaeger 2016-02-29 18:22:24 UTC
Maybe this script should become part of sysutils/fusefs-kmod ?
Comment 2 Rick Macklem 2016-03-01 00:06:58 UTC
Well, for FreeBSD10 (and later) the fuse module is in the kernel and not a port. As such, I think the rc scripts should be fixed to handle this. (I am not an rc.d guy, so I do not know if this script is the best way to fix things.)
Comment 3 rkoberman 2016-03-01 06:07:13 UTC
Minor detail... under 10 (and head) fuse is built as a kernel module. It is not in GENERIC. The kmod is only used on 9. There are also significant difference in user-side code in 9. I am not confident that this is needed there. I only ran into the corruption issue after I started using the base-system patches while they were under test and development. (I had a LOT of other issues with the old fuse, so this might have been hidden by more other issues.) Because of this, I'm not at all sure that it belongs in the kmod port, though it might. I think that it does belong in the base system /etc/rc.d in 10 and head.
Comment 4 Edward Tomasz Napierala 2017-04-25 20:06:57 UTC
FWIW, you might be able to replace this loop, greps etc with "umount -At fusefs".
Comment 5 rkoberman 2017-04-28 01:20:57 UTC
Created attachment 182140 [details] Init script to unmount fusefs file systems before daemon exits Updated script to use '-Avt fusefs' and eliminate the loop
Comment 7 Alan Somers 2019-03-21 20:50:47 UTC
This sounds like a bug in the particular fuse daemons you're using. Every fuse daemon should be able to cleanly shutdown on SIGTERM, and by default the kernel doesn't cache writes to fuse filesystems. But perhaps the early patches you were using did. Does the problem still happen on any recent releases?
Comment 8 rkoberman 2019-03-22 22:13:50 UTC
(In reply to Alan Somers from comment #7) You may be right. I only saw the issue with ntfs-3g (sysutils/fusefs-ntfs). If I shutdown my system with an NTFS volume mounted and after the file system had been written to, I would see corruption. I would be unable to open many directories and get lots of file system errors. Files would simply be gone. I would boot up Windows 7 and run a file check which claimed the volume was OK and asked whether I wanted to run the full check. The full check reported errors and required a reboot to fix the problem. After the rebuild completed, the file system would mount and run fine on FreeBSD. In a mail thread, someone, probably either Florian Smeets or Attilio Rao, it was suggested that the fuse daemon was likely existing before the file system was unmounted completely and that led me to write a simple rc.d script to unmount all FUSE file systems (umount -Avt fusefs) during shutdown. Since then, I have seen no corruption issues. (I have seen other issues, notably confusion between mtime and ctime on files. This all goes back to around 2012, so my memory is hazy.
Comment 9 Alan Somers 2019-03-22 22:19:29 UTC
Ok, I'm going to close this bug on the theory that it was either caused by: 1) Buggy write caching in the fuse driver, which no longer happens, or 2) Poor handling of SIGETERM in fusefs-ntfs3g But if anybody can reproduce the problems on a modern system, then by all means reopen.