05.12.2018 7:12, Malcolm пишет:
On Tue 04 Dec 2018 09:36:08 PM CST, simonizor wrote:
On Tuesday, December 4, 2018 9:17:41 PM CST, Larry Finger wrote: ...
This corruption issue seems to be caused by blk-mq mode (which doesn't seem to be enabled by default). It is also not limited to ext4. There have been reports of it happening on other file systems also.
You can check if you have it enabled by doing the following:
Checking if a drive is using the multi-queue I/O code can be done by checking for the presence of the /sys/block/DEVICE/mq directory.
More info: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-EXT4-Issue-Likely-MQ
Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=201685
Fix for this bug: https://bugzilla.kernel.org/show_bug.cgi?id=201685#c255 Hi It's been present for awhile now, just not default;
dmesg | grep "io scheduler"
[ 2.793001] io scheduler noop registered [ 2.793004] io scheduler deadline registered [ 2.793050] io scheduler cfq registered (default) [ 2.793052] io scheduler mq-deadline registered [ 2.793052] io scheduler kyber registered [ 2.793100] io scheduler bfq registered
I've been using the mq i/o scheduler with btrfs/xfs on ssd's no issues seen to date.
cat /sys/block/sd[a,b]/queue/scheduler [mq-deadline] kyber bfq none [mq-deadline] kyber bfq none
According to Chris Mason, "It triggers when you have scsi devices using elevator=none over blkmq". https://lore.kernel.org/linux-btrfs/FEDBF117-C83C-4DEC-96D1-A549DBCF4950@fb.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org