https://bugzilla.kernel.org/show_bug.cgi?id=201685 --- Comment #206 from Jimmy.Jazz@xxxxxxx --- 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.
