Bug 200513 - [FUSEFS] Race at shutdown and corrupt fusefs systems
Summary: [FUSEFS] Race at shutdown and corrupt fusefs systems
Status: Closed Not Enough Information
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.1-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-29 05:50 UTC by rkoberman
Modified: 2019-03-22 22:19 UTC (History)
8 users (show)

See Also:


Attachments
init script to umount fusefs file systems prior to the termination of the daemon (448 bytes, text/plain)
2015-05-29 05:50 UTC, rkoberman
no flags Details
Init script to unmount fusefs file systems before daemon exits (380 bytes, text/plain)
2017-04-28 01:20 UTC, rkoberman
no flags Details
Fix typo in script (379 bytes, text/plain)
2017-04-28 01:23 UTC, rkoberman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 freebsd_committer freebsd_triage 2016-02-29 18:22:24 UTC
Maybe this script should become part of sysutils/fusefs-kmod ?
Comment 2 Rick Macklem freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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 6 rkoberman 2017-04-28 01:23:07 UTC
Created attachment 182141 [details]
Fix typo in script
Comment 7 Alan Somers freebsd_committer freebsd_triage 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 freebsd_committer freebsd_triage 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.