Date: Fri, 22 Mar 2019 22:13:50 +0000 From: bugzilla-noreply@freebsd.org To: fs@FreeBSD.org Subject: [Bug 200513] [FUSEFS] Race at shutdown and corrupt fusefs systems Message-ID: <bug-200513-3630-P6eNWulcTG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-200513-3630@https.bugs.freebsd.org/bugzilla/> References: <bug-200513-3630@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D200513 --- Comment #8 from rkoberman@gmail.com --- (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.=20 After the rebuild completed, the file system would mount and run fine on FreeBSD. In a mail thread, someone, probably either Florian Smeets or Attil= io Rao, it was suggested that the fuse daemon was likely existing before the f= ile system was unmounted completely and that led me to write a simple rc.d scri= pt 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. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-200513-3630-P6eNWulcTG>