[Bug 201685] ext4 file system corruption

[bugzilla-daemon@bugzilla.kernel.org]

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

--- Comment #46 from Theodore Tso (tytso@mit.edu) ---
So Henrique, the only difference between the 4.19.3 kernel that worked and the
one where you didn't see corruption was CONFIG_SCSI_MQ_DEFAULT?   Can you diff
the two configs to be sure?

What can you tell us about the SSD?  Is it a SATA-attached SSD, or
NVMe-attached?

What I can report is my personal development laptop is running 4.19.0 (plus the
ext4 patches that landed in 4.20-rc1) with CONFIG_SCSI_MQ_DEFAULT=n?  (Although
as others have pointed out, that shouldn't matter since my SSD is
NVMe-attached, and so it doesn't go through the SCSI stack.)   My laptop runs
Debian unstable, and uses an encrypted LUKS partition on top of which I use
LVM.   I do use regular suspend-to-ram (not suspend-to-idle, since that burns
way too much power; there's a kernel BZ open on that issue) since it is a
laptop.

I have also run xfstest runs using 4.19.0, 4.19.1, 4.19.2, and 4.20-rc2 with
CONFIG_SCSI_MQ_DEFAULT=n; it's using the gce-xfstests[1] test appliance which
means I'm using virtio-SCSI on top of LVM, and it runs a large number of
regression tests, many with heavy read/write loads, but none of the file
systems is mounted for more than 5-6 minutes before we unmount and then run
fsck on it.  We do *not* do any suspend/resumes, although we do test the file
system side of suspend/resume using the freeze and thaw ioctls.  There were no
unusual problems noticed.  

[1] https://thunk.org/gce-xfstests

I have also run gce-xfstests on 4.20-rc2 with CONFIG_SCSI_MQ_DEFAULT=y, with
the same configuration as above --- vrtio-scsi with LVM on top.   There was
nothing unusual that was detected there.

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