Date:   Mon, 03 Dec 2018 18:05:46 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...r.kernel.org
Subject: [Bug 201685] ext4 file system corruption

https://bugzilla.kernel.org/show_bug.cgi?id=201685

--- Comment #206 from Jimmy.Jazz@....net ---
fsck does i/o itself. It doesn't aggravate or trigger the issue. Also, I can't
believe it is just an hdd, sata or usb hardware problem.

Moreover, it affects other type of file systems zfs or nfs for instance (what
about ext3 and ext2 ?). So it should imply the code they share.

Three ideas I hope not so stupid.

+ log journal
On my computers, vmlinuz is written on an ext2 /boot file system every kernel
upgrade. If I remember well ext2 never failed and the file system stayed clean
during the tests.
If ext2 is not affected, it could involve the journal code instead.

+ if that's not the log, than the cache.
In my case, rsync and rm are involved in the file system corruption. It could
be explained like that. rsync reads inodes and blocs to compare before any
write. The kernel reports an inconsistency independently if the inode/bloc is
read or written from/to the cache. As expected only the changes are sent to the
media. It explains that some of the corruptions never reached the media and the
next reboot fsck declares a disk clean because only read i/o has been done
before the reboot.

+ what about synchronisation
As I mention in other posts, even if the issue still lurks, the patch proposed
here makes the issue less intrusive. 

My tests were made with a vanilla kernel source from gentoo portage
sys-kernel/vanilla-sources

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

Powered by blists - more mailing lists