linux-kernel - Re: 2.6.18-rc2, problem to wake up spinned down drive?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 09 Aug 2006 03:59:13 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Bill Davidsen <davidsen@....com>
CC:	Harald Dunkel <harald.dunkel@...nline.de>,
	Pavel Machek <pavel@....cz>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: 2.6.18-rc2, problem to wake up spinned down drive?

Bill Davidsen wrote:
>> I think the solution to your problem is adjusting command timeout to 
>> more reasonable values which should make the problem more bearable. 
>> It'll take some time to figure out how to make timeouts more 
>> intelligent without breaking support for slow devices.  I'll work on 
>> that. 
> 
> Tejun, would it be possible and sensible to either let the user tune 
> this per-drive, or to have the kernel note how long {something} takes 
> and auto-tune to that? As you said, the issue is not breaking slow devices.

I think the driver can be made to have sufficient static intelligence to 
not require user or auto tuning.  !BUSY wait in pre/postreset which are 
often cause of unnecessary 30s delay during recovery can be avoided by...

1. for !hotplug, waiting for BSY before reset doesn't make sense in the 
first place (why would we be resetting the device if it can clear BSY?)

2. for hotplug, we can make things much more intelligent.  e.g. try 
prereset waiting and softreset from 0-5s, then hardresets 5-10s, 10-15s, 
15-30s and 30s-60s, which will guarantee 1. slow device is given full 
idle 30s to get ready eventually  2. recovery reset is complete in 60s, 
while giving fast devices several chances to be fast.

And, for IO command timeouts, some operating system is said to use 7s 
timeout for ATA IO commands and simply adopting that value would be good 
enough.  We also can choose more agressive timeouts for some EH commands 
(IDNTIFY, SET_FEATURES...).

With all above combined, EH recovery should be pretty snappy and 
recovery time well-bound.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/