You are not logged in.
I'm using Arch Linux (as a home server), and after updating to `4.19.4` (from `4.19.2`), I started having problems where processes trying to access data on /dev/md127 (my raid1, mounted at /home) would get stalled in D state for a few minutes up to a few hours, after which everything would go back to normal. Since it's mounted at /home, even trying to SSH in would leave me not being able to do anything, since the shell starts on my home folder.
I have more disks on that server (but only those two as raid1), and those are the only ones that suffer from that problem.
I beleive this is caused by that kernel version, since I've installed `4.9 LTS` and that has been working just fine for the past few days... But it's weird that the problem persists even on `4.19.12`, which is a few versions ahead the one where my problems started.
Is there anything I can do to debug this?
Thanks in advance.
Offline
I would suggest either testing if 4.19.3 is affected then bisect between the affected and unaffected stable releases or trying 4.20.
Offline
Don't use the new multi-threaded scehduler /queue (mq) stuff which is now the default; it really does not live well with raid1.
Addding:
scsi_mod.use_blk_mq=0 to the kernel options in the boot loaded should fix it.
Offline
Don't use the new multi-threaded scehduler /queue (mq) stuff which is now the default; it really does not live well with raid1.
Addding:scsi_mod.use_blk_mq=0to the kernel options in the boot loaded should fix it.
Trying that, fingers crossed, thanks! ![]()
Last edited by EduAlmeida (2018-12-26 19:31:43)
Offline
The new kernel 4.20.0-arch1 seems so far to have solved the problem as well, with mq-deadline on RAID1
Offline
Too soon. First 5 minute D state hang on 4.20 with mq; back to
scsi_mod.use_blk_mq=0Offline
@stronnag you might want to work with upstream to resolve the issue before 4.21 introduces https://git.kernel.org/pub/scm/linux/ke … 029b0ec0e6
Offline