3 ms·
This is probably not as serious as the title implies, and apparently not related to the recent reports of EXT4 corruptions. Quoting [0] Theodore Ts'o: >So it's
by tux3 11y ago
This is probably not as serious as the title implies, and apparently not related to the recent reports of EXT4 corruptions.
Quoting [0] Theodore Ts'o:
>So it's pretty hard to hit this bug by accident
>It requires the combination of (a) writing to a portion of a file that
was not previously allocated using buffered I/O, (b) an fallocate of a
region of the file which is a superset of region written in (a) before
it has chance to be written to disk, (c) waiting for the file data in
(a) to be written out to disk (either via fsync or via the writeback
daemons), and then (d) before the extent status cache gets pushed out
of memory, another random write to a portion of the file covered by
(a) -- in which case that specific portion of (a) could be replaced by
all zeros.
[0] http://thread.gmane.org/gmane.linux.kernel/1956583 http://thread.gmane.org/gmane.linux.kernel/1956583
- digi_owl 11y agoReminds me of corruption issues that came from HDD controllers reshuffling writes so that the logs and the actual data got desynced. Only really noticed if you got a power failure and hit the drive with a fsck afterwards. The fix was to toggle on write barriers.
- karavelov 11y agoMy guess is that it is something related the RAID handling in the block layer: I had a corruption on fat32 fs (/boot/efi partition) after upgrading grub-efi on my laptop. It sits on md-raid0 (intel fake raid) I also had multiple corruptions of files written on ext4 patition but the /boot/efi corruption rules out ext4 bug. EDIT: It was with 4.0.2 kernel on Debian