Re: Default IDENTIFY timeout is 5000ms which is too short for enterprise disks

[Niklas Cassel <cassel@kernel.org>]

Hello Alan,

On Thu, Apr 23, 2026 at 10:26:55PM +0800, AlanCui4080 wrote:
> Thank you for your really really detailed response. And i was surprised by your
> reply, hopefully that doesn't cost your time too much.

My pleasure :)


> I'm not a native speaker so the actually question that i want to ask is that
> will kernel do quirk for those drives so let it just don't fail to avoid costing
> extra 5 seconds and producing annoying erros on console?

Well, considering that the controller does not send a reply when it is
supposed to, I think that the error in the log is justified.


You also wrote that:
> I enlong the timeout, then this problem is being "relaxed", during 10
> recoveries, only 2 times the revalidation failed.

So as far as I can tell, even increasing the timeout does not solve the
problem in all cases.

So, right now, I can't even think of a way to quirk the device so that it
works reliably.


> > But as soon as you get a shell after a system resume, the above command
> > succeeds, right?
> 
> Yes, that's correct.

Great!


> > My suggestion is to look at the zpool code to see how long it waits to finds
> > all devices after a system resume before it kicks devices off the RAID array.
> > 
> > My initial feeling is that if your device is ready after 5 seconds after a
> > system resume, then the timeout value for zpool to kick off a device must be
> > very low.
> 
> I do believe that's about zpool, i migrated it into btrfs RAID now, it works very
> well. And if you want to know, the timeout of TXG to commit is 5000ms also.

Nice to hear that you are not seeing the same issue with btrfs.


Kind regards,
Niklas