Bugzilla – Bug 404758
Fuse corrupt filesystem data when written to disk?
Last modified: 2008-10-29 11:04:34 UTC
Caveat- This is less of a bug report and more of a story. I have no debug logs to offer due to fs corruption. Consider this a heads up on the Fuse usermode filesystem manager. The Fuse component of Gnome-VFS seems to corrupt data at a filesystem level when writing to disk. The affected system is SuSe 11 32-bit. Kernel is 2.6.25.5-1.1-pae. Hardware is: Athlon XP 3200+ 2 GB RAM Asus A7V8X-E Deluxe mobo 3ware 9500S 4 port controller 4 X 250GB WD HD M-Audio Revolution 7.1 PCI sound Plexter DVD+-R Initially, filesystem errors were logged to /var/log/messages stating the /dev/sda2 was in error. Fsck'd and the filesystem was corrupted and unrepairable. Sectors were readable but had erroneous names. No smart errors detected on standalone drives via WD utility. Was formatted and repartitioned. Reinstalled OS. File corruption persisted on fresh install. CRC errors on every file written to disk after initial install. Default settings. KDE3 or 4 desktop default. Although the install itself was flawless. Everything worked, but as soon as something was written to disk- it had corruption. The drives were replaced with a new one's. OS reinstalled. The error was again /dev/sda2. Although sda2 was an array(2 drives) and with new drives. Filesystem slipped to read only thereafter. Reinstalled with new drives again. Persistent corruption when writing to disk. zip/tar.gz files could not be read. No /var/log/message errors. No raid controller errors. No drive errors. Found no errors in logs. Gnome-vfs/fuse locked /home/user/.gvfs directory. No user could access, not root or the owner(user themselves). Was the only directory on the OS that could not be read. Gvf-Fuse uninstalled. Processes killed. Downloaded and transferred files. No longer having file corruption. Directory .gvfs was then accessible by user. rm -rf'd. I have since fallen back to Suse 10.3 due to criticality of this bug. 10.3 works fine. I know this isn't a typical bug report, but it's hard to record ether. Thanks for listening.
I don't think this error was related to GVFS-Fuse or GVFS itself. What you were seeing as a "locked" $HOME/.gvfs dir was most likely caused by a crashed instance of the GVFS-Fuse daemon - others have seen this too, and it's harmless. There is a remote chance that the Fuse kernel module interfered with the disk I/O somehow, but that would be a kernel bug and not a GVFS bug. I'm going to reassign this to the kernel team so you can continue the investigation with them if you'd like to do that.
Created attachment 233902 [details] alsa-info
Sorry, not here. please delete
Thanks for the report, but without logs it's virtually impossible to tell what happened. I find it unlikely that the cause of the corruption would be Gnome-VFS or fuse. My initial guess would be a problem with the 3ware driver in the OpenSUSE-11.0 kernel, but the only significant change recently to this driver was commit 1e6c38cec08f88b0df88a34e80f15492cace74e9 Author: Tony Battersby <tonyb@cybernetics.com> Date: Fri Nov 9 13:04:35 2007 -0500 [SCSI] 3w-9xxx: fix abysmal write performance on some motherboards and it doesn't look like it could be causing corruption. But I haven't got much clue about scsi drivers. The problems you have been seeing with ~/.gvfs are probably just a result of the big problems due to file corruption. If ~/.gvfs is not accessible might be a bug in GVFS-Fuse, but it's not the kind of bug that would cause disk corruption. So I very much suspect that the cause-effect is the other way round: the corruption is causing GVFS to crash, and not GVFS is causing the corruption. Hannes, could you comment on the possibility of this being a driver issue? Thanks.
Quite unlikely. But can't be sure as I would need some logs to confirm this.
Henry, would you be willing to try to reproduce and save some logs? Even messages from fsck may give some clues about the source of the corruption, if there's nothing in /var/log/messages. Thanks.
Oh, and if kernel messages couldn't make it to disk because it was remounted read-only, you should still be able to save dmesg to a temporary file: dmesg > /dev/shm/dmesg scp /dev/shm/dmesg user@machine:
No activity for two months, closing with NORESPONSE. If new info is available please reopen. Thanks.