[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <bug-201685-13602-MMYw9VUJcw@https.bugzilla.kernel.org/>
Date: Sun, 02 Dec 2018 19:34:40 +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 #163 from Jukka Santala (donwulff@....fi) ---
First report specifies AMD, second report is Intel, and so on. I agree more
detailed system information might help find commonalities and false positives,
but the cross-platform nature of the problem seemed established right from the
start.
AMD Phenom(tm) II X4 B50 Processor, SSHD ST1000LM014-1EJ164
[11514.358542] EXT4-fs error (device dm-0): ext4_iget:4831: inode #18288150:
comm cp: bad extra_isize 49917 (inode size 256)
[11514.386613] Aborting journal on device dm-0-8.
[11514.389070] EXT4-fs (dm-0): Remounting filesystem read-only
Errors for each of the inodes on the block follow, until I dropped filesystem
caches (drop_caches 3) and accessed them again and they were fine. Corrupted
block looked random binary, but not compressed. BTRFS was reporting csum errors
every time I dropped caches, which makes me wonder if people having the problem
are using BTRFS?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Powered by blists - more mailing lists