[Bug 245186] zfs panic despite failmode=continue
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Tue Mar 31 21:16:54 UTC 2020
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=245186
--- Comment #2 from John F. Carr <jfc at mit.edu> ---
I understand it's a different path internally, but I asked for disk errors not
to crash the system and that's what I expect to happen.
The code in spa_misc.c appears to allow 1,000 seconds. I've seen sync take a
significant fraction of that time with working disks. I/O on a failing disk
can be orders of magnitude slower than usual. It might take seems like forever
to work through the queue, but the driver is continuing to process I/O
requests.
Unfortunately based on comments the deadman timer is based on the oldest
pending I/O. If the kernel used a per-disk timer that counted time with a
non-empty queue and no requests completing it would be able to distinguish a
very slow disk from a hung driver. Or it could maintain some counter of failed
I/O and mark the disk dead when the rate got too high.
I think the drive should be kicked out of the pool and its I/O queue flushed in
this situation. When my drive first started failing that's what happened. I'd
run zpool status and find one of the drives removed. I could run geli attach
and a zpool command to bring it back in until the next time it got kicked out.
More recently the system started crashing instead.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list