Re: [git patch] libata resume fix

Re: [git patch] libata resume fix

[Robert Hancock]

Bill Davidsen wrote:
> The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
> lot of design changes to make it spin up quickly, and improve a function 
> which is usually done on a server once every MTBF when replacing the 
> failed unit.
> 
> I think the majority of very large or very fast drives are in systems 
> which don't (deliberately) power cycles often, in rooms where heat is an 
> issue. And to spin up quickly take a larger power supply... 30 sec is 
> fine with most users.
> 
> Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
> seek sure is fast!

I wouldn't guess that even a 15K drive would take nearly that long. For 
boot time on servers it doesn't matter much though, disk spinup time is 
in the noise compared to the insane BIOS delays on most of them during 
bootup. Like on some servers (ahem.. IBM) which have about a 15 second 
delay on the main BIOS screen, 10 second delays on every network boot 
ROM, a 1 minute delay on the SCSI controller before it even starts 
scanning the bus, then another good 10 seconds before it starts booting. 
Gets annoying after a few reboots..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: [git patch] libata resume fix

[Jens Axboe]

On Wed, May 31 2006, Robert Hancock wrote:
> Bill Davidsen wrote:
> >The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
> >lot of design changes to make it spin up quickly, and improve a function 
> >which is usually done on a server once every MTBF when replacing the 
> >failed unit.
> >
> >I think the majority of very large or very fast drives are in systems 
> >which don't (deliberately) power cycles often, in rooms where heat is an 
> >issue. And to spin up quickly take a larger power supply... 30 sec is 
> >fine with most users.
> >
> >Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
> >seek sure is fast!
> 
> I wouldn't guess that even a 15K drive would take nearly that long. For 
> boot time on servers it doesn't matter much though, disk spinup time is 

I do use a 15K rpm drive in my workstation (hello git!), and the spin up
really isn't that bad. Less than 10 seconds for the actual spin up, I
would say.

> in the noise compared to the insane BIOS delays on most of them during 
> bootup. Like on some servers (ahem.. IBM) which have about a 15 second 
> delay on the main BIOS screen, 10 second delays on every network boot 
> ROM, a 1 minute delay on the SCSI controller before it even starts 
> scanning the bus, then another good 10 seconds before it starts booting. 
> Gets annoying after a few reboots..

Indeed, the BIOS bootup time on servers is typically anywhere from
really bad to truly awful.

-- 
Jens Axboe

Re: [git patch] libata resume fix

[Bill Davidsen]

Jens Axboe wrote:

>On Wed, May 31 2006, Robert Hancock wrote:
>  
>
>>Bill Davidsen wrote:
>>    
>>
>>>The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
>>>lot of design changes to make it spin up quickly, and improve a function 
>>>which is usually done on a server once every MTBF when replacing the 
>>>failed unit.
>>>
>>>I think the majority of very large or very fast drives are in systems 
>>>which don't (deliberately) power cycles often, in rooms where heat is an 
>>>issue. And to spin up quickly take a larger power supply... 30 sec is 
>>>fine with most users.
>>>
>>>Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
>>>seek sure is fast!
>>>      
>>>
>>I wouldn't guess that even a 15K drive would take nearly that long. For 
>>boot time on servers it doesn't matter much though, disk spinup time is 
>>    
>>
>
>I do use a 15K rpm drive in my workstation (hello git!), and the spin up
>really isn't that bad. Less than 10 seconds for the actual spin up, I
>would say.
>  
>
Sounds about right, but clearly longer than the 2 sec mentioned early in 
this thread. I think a long delay is okay as long as it gets stopped 
when the drive does come ready.

>  
>
>>in the noise compared to the insane BIOS delays on most of them during 
>>bootup. Like on some servers (ahem.. IBM) which have about a 15 second 
>>delay on the main BIOS screen, 10 second delays on every network boot 
>>ROM, a 1 minute delay on the SCSI controller before it even starts 
>>scanning the bus, then another good 10 seconds before it starts booting. 
>>Gets annoying after a few reboots..
>>    
>>
>
>Indeed, the BIOS bootup time on servers is typically anywhere from
>really bad to truly awful.
>
>  
>
I try *very* hard not to do bootup on servers, the paperwork involved 
with an outage takes longer than the boot time ;-)

-- 
bill davidsen <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: [git patch] libata resume fix

[Tejun Heo]

Hi, Jens.

Jens Axboe wrote:
> On Wed, May 31 2006, Robert Hancock wrote:
>> Bill Davidsen wrote:
>>> The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
>>> lot of design changes to make it spin up quickly, and improve a function 
>>> which is usually done on a server once every MTBF when replacing the 
>>> failed unit.
>>>
>>> I think the majority of very large or very fast drives are in systems 
>>> which don't (deliberately) power cycles often, in rooms where heat is an 
>>> issue. And to spin up quickly take a larger power supply... 30 sec is 
>>> fine with most users.
>>>
>>> Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
>>> seek sure is fast!
>> I wouldn't guess that even a 15K drive would take nearly that long. For 
>> boot time on servers it doesn't matter much though, disk spinup time is 
> 
> I do use a 15K rpm drive in my workstation (hello git!), and the spin up
> really isn't that bad. Less than 10 seconds for the actual spin up, I
> would say.

Can you measure spin up time for your 15k's?  Some controllers can't 
catch the first D2H FIS after POR and have to wait unconditionally for 
spin up for hotplug & resuming from suspend.  Currently 8 sec wait is 
used but it seems insufficient for your drives.  Failing to spinup in 
that 8 secs would probably result in timeout of the first reset attempt 
and retrial - which currently takes > 30 secs.

Spin-up time can be measured by first issuing STANDBY and then time how 
long IDLE IMMEDIATE takes, I think.

Thanks.

-- 
tejun

Re: [git patch] libata resume fix

[Jens Axboe]

On Tue, Jun 06 2006, Tejun Heo wrote:
> Hi, Jens.
> 
> Jens Axboe wrote:
> >On Wed, May 31 2006, Robert Hancock wrote:
> >>Bill Davidsen wrote:
> >>>The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
> >>>lot of design changes to make it spin up quickly, and improve a function 
> >>>which is usually done on a server once every MTBF when replacing the 
> >>>failed unit.
> >>>
> >>>I think the majority of very large or very fast drives are in systems 
> >>>which don't (deliberately) power cycles often, in rooms where heat is an 
> >>>issue. And to spin up quickly take a larger power supply... 30 sec is 
> >>>fine with most users.
> >>>
> >>>Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
> >>>seek sure is fast!
> >>I wouldn't guess that even a 15K drive would take nearly that long. For 
> >>boot time on servers it doesn't matter much though, disk spinup time is 
> >
> >I do use a 15K rpm drive in my workstation (hello git!), and the spin up
> >really isn't that bad. Less than 10 seconds for the actual spin up, I
> >would say.
> 
> Can you measure spin up time for your 15k's?  Some controllers can't 
> catch the first D2H FIS after POR and have to wait unconditionally for 
> spin up for hotplug & resuming from suspend.  Currently 8 sec wait is 
> used but it seems insufficient for your drives.  Failing to spinup in 
> that 8 secs would probably result in timeout of the first reset attempt 
> and retrial - which currently takes > 30 secs.
> 
> Spin-up time can be measured by first issuing STANDBY and then time how 
> long IDLE IMMEDIATE takes, I think.

The 15K RPM is a SCSI drive, I haven't seen any SATA 15K rpm drives yet.
I have the same model in another box, I can measure spinup with
START_STOP unit there. I will do so later today, when I fire it up, if
you still want to know?

-- 
Jens Axboe

Re: [git patch] libata resume fix

[Tejun Heo]

Jens Axboe wrote:
>> Can you measure spin up time for your 15k's?  Some controllers can't 
>> catch the first D2H FIS after POR and have to wait unconditionally for 
>> spin up for hotplug & resuming from suspend.  Currently 8 sec wait is 
>> used but it seems insufficient for your drives.  Failing to spinup in 
>> that 8 secs would probably result in timeout of the first reset attempt 
>> and retrial - which currently takes > 30 secs.
>>
>> Spin-up time can be measured by first issuing STANDBY and then time how 
>> long IDLE IMMEDIATE takes, I think.
> 
> The 15K RPM is a SCSI drive, I haven't seen any SATA 15K rpm drives yet.
> I have the same model in another box, I can measure spinup with
> START_STOP unit there. I will do so later today, when I fire it up, if
> you still want to know?
> 

Arggh.. Confused w/ 10k drives.  But it would be nice to know spin-up 
time for 15k's if it doesn't waste too much of your time.

Thanks.

-- 
tejun

[git patch] libata resume fix

[Jeff Garzik]

Please pull from 'upstream-fixes' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

to receive the following updates:

 drivers/scsi/libata-core.c |    1 +
 1 file changed, 1 insertion(+)

Mark Lord:
      the latest consensus libata resume fix

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index fa476e7..b046ffa 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -4297,6 +4297,7 @@ static int ata_start_drive(struct ata_po
 int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
 {
 	if (ap->flags & ATA_FLAG_SUSPENDED) {
+		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
 		ap->flags &= ~ATA_FLAG_SUSPENDED;
 		ata_set_mode(ap);
 	}

Re: [git patch] libata resume fix

[Benjamin Herrenschmidt]

On Sun, 2006-05-28 at 16:34 -0400, Jeff Garzik wrote:
> Please pull from 'upstream-fixes' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> 
> to receive the following updates:
> 
>  drivers/scsi/libata-core.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> Mark Lord:
>       the latest consensus libata resume fix

If your devices are coming from poweron-reset then you will have to wait
up to 31 seconds :( And yes, I _did_ have such a device at one point.

Ben.


> diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
> index fa476e7..b046ffa 100644
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -4297,6 +4297,7 @@ static int ata_start_drive(struct ata_po
>  int ata_device_resume(struct ata_port *ap, struct ata_device *dev)
>  {
>  	if (ap->flags & ATA_FLAG_SUSPENDED) {
> +		ata_busy_wait(ap, ATA_BUSY | ATA_DRQ, 200000);
>  		ap->flags &= ~ATA_FLAG_SUSPENDED;
>  		ata_set_mode(ap);
>  	}
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [git patch] libata resume fix

[Mark Lord]

Benjamin Herrenschmidt wrote:
> On Sun, 2006-05-28 at 16:34 -0400, Jeff Garzik wrote:
>> Please pull from 'upstream-fixes' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
>>
>> to receive the following updates:
>>
>>  drivers/scsi/libata-core.c |    1 +
>>  1 file changed, 1 insertion(+)
>>
>> Mark Lord:
>>       the latest consensus libata resume fix
> 
> If your devices are coming from poweron-reset then you will have to wait
> up to 31 seconds :( And yes, I _did_ have such a device at one point.

Not in a suspend/resume capable notebook, though.

I don't know of *any* notebook drives that take longer
than perhaps five seconds to spin-up and accept commands.
Such a slow drive wouldn't really be tolerated by end-users,
which is why they don't exist.

But I suppose people will want to suspend/resume bigger machines
too, in which case a 10000rpm Raptor might need 15 seconds or so.

We could bump up the existing timeout, I suppose.

Perhaps Jeff could comment on any potential harm in libata
for going all the way to 3100000 with the timeout?

Cheers

Re: [git patch] libata resume fix

[Linus Torvalds]

On Tue, 30 May 2006, Mark Lord wrote:
> 
> Not in a suspend/resume capable notebook, though.
> 
> I don't know of *any* notebook drives that take longer
> than perhaps five seconds to spin-up and accept commands.
> Such a slow drive wouldn't really be tolerated by end-users,
> which is why they don't exist.

Indeed. In fact, I'd be surprised to see it in a desktop too.

At least at one point, in order to get a M$ hw qualification (whatever 
it's called - but every single hw manufacturer wants it, because some 
vendors won't use your hardware if you don't have it), a laptop needed to 
boot up in less than 30 seconds or something.

And that wasn't the disk spin-up time. That was the time until the Windows 
desktop was visible.

Desktops could do a bit longer, and I think servers didn't have any time 
limits, but the point is that selling a disk that takes a long time to 
start working is actually not that easy. 

The market that has accepted slow bootup times is historically the server 
market (don't ask me why - you'd think that with five-nines uptime 
guarantees you'd want fast bootup), and so you'll find large SCSI disks in 
particular with long spin-up times. In the laptop and desktop space I'd be 
very surprised to see anythign longer than a few seconds.

		Linus

Re: [git patch] libata resume fix

[Ric Wheeler]

Linus Torvalds wrote:

>On Tue, 30 May 2006, Mark Lord wrote:
>  
>
>>Not in a suspend/resume capable notebook, though.
>>
>>I don't know of *any* notebook drives that take longer
>>than perhaps five seconds to spin-up and accept commands.
>>Such a slow drive wouldn't really be tolerated by end-users,
>>which is why they don't exist.
>>    
>>
>
>Indeed. In fact, I'd be surprised to see it in a desktop too.
>
>At least at one point, in order to get a M$ hw qualification (whatever 
>it's called - but every single hw manufacturer wants it, because some 
>vendors won't use your hardware if you don't have it), a laptop needed to 
>boot up in less than 30 seconds or something.
>
>And that wasn't the disk spin-up time. That was the time until the Windows 
>desktop was visible.
>
>Desktops could do a bit longer, and I think servers didn't have any time 
>limits, but the point is that selling a disk that takes a long time to 
>start working is actually not that easy. 
>
>The market that has accepted slow bootup times is historically the server 
>market (don't ask me why - you'd think that with five-nines uptime 
>guarantees you'd want fast bootup), and so you'll find large SCSI disks in 
>particular with long spin-up times. In the laptop and desktop space I'd be 
>very surprised to see anythign longer than a few seconds.
>
>		Linus
>  
>
With many data centera applications, delayed spin up of SCSI (and 
increasingly S-ATA) drives is a feature meant to avoid blowing a circuit 
when you spin up too many drives at once ;-)

Ric

Re: [git patch] libata resume fix

[Benjamin Herrenschmidt]

On Tue, 2006-05-30 at 11:26 -0700, Linus Torvalds wrote:
> 
> On Tue, 30 May 2006, Mark Lord wrote:
> > 
> > Not in a suspend/resume capable notebook, though.
> > 
> > I don't know of *any* notebook drives that take longer
> > than perhaps five seconds to spin-up and accept commands.
> > Such a slow drive wouldn't really be tolerated by end-users,
> > which is why they don't exist.
> 
> Indeed. In fact, I'd be surprised to see it in a desktop too.

Seen some drives at one point (I think those were maxtor) that take
_exactly_ 30 seconds to stop asserting BUSY after a HW reset.

> At least at one point, in order to get a M$ hw qualification (whatever 
> it's called - but every single hw manufacturer wants it, because some 
> vendors won't use your hardware if you don't have it), a laptop needed to 
> boot up in less than 30 seconds or something.
> 
> And that wasn't the disk spin-up time. That was the time until the Windows 
> desktop was visible.

Doesn't window spin drives asynchronously ? The main problem I've seen
in practice (appart from the above maxtor drives) are ATAPI CD/DVD
drives. There are whole generations of those that will happily drive
your bus to some crazy state (even when only slave and not selected) for
a long time while they spin up and try to identify the disk in them on a
hard reset (and if they have trouble identifying the disk, like a
scratched disk, that can take a loooong time).
  
> Desktops could do a bit longer, and I think servers didn't have any time 
> limits, but the point is that selling a disk that takes a long time to 
> start working is actually not that easy. 
> 
> The market that has accepted slow bootup times is historically the server 
> market (don't ask me why - you'd think that with five-nines uptime 
> guarantees you'd want fast bootup), and so you'll find large SCSI disks in 
> particular with long spin-up times. In the laptop and desktop space I'd be 
> very surprised to see anythign longer than a few seconds.

It's only a timeout. If you drives are fast, it will come up fast... if
you drives are slow, it will come up slow, and if your drives are
broken, you'll wait at most 31 seconds. Seems ok to me... It would be
nicer in the long run if libata could resume asynchronously (by keeping
the request queue blocked until full resume and polling the BUSY from a
thread or a timer), but I don't think we should lower the timeout.

Ben.

Re: [git patch] libata resume fix

[Jens Axboe]

On Wed, May 31 2006, Benjamin Herrenschmidt wrote:
> > At least at one point, in order to get a M$ hw qualification (whatever 
> > it's called - but every single hw manufacturer wants it, because some 
> > vendors won't use your hardware if you don't have it), a laptop needed to 
> > boot up in less than 30 seconds or something.
> > 
> > And that wasn't the disk spin-up time. That was the time until the Windows 
> > desktop was visible.
> 
> Doesn't window spin drives asynchronously ? The main problem I've seen
> in practice (appart from the above maxtor drives) are ATAPI CD/DVD
> drives. There are whole generations of those that will happily drive
> your bus to some crazy state (even when only slave and not selected) for
> a long time while they spin up and try to identify the disk in them on a
> hard reset (and if they have trouble identifying the disk, like a
> scratched disk, that can take a loooong time).

FWIW, I've seen the very same thing. Resume/power-up with a cd/dvd that
has a media loaded can take _ages_ to get ready.

> > Desktops could do a bit longer, and I think servers didn't have any time 
> > limits, but the point is that selling a disk that takes a long time to 
> > start working is actually not that easy. 
> > 
> > The market that has accepted slow bootup times is historically the server 
> > market (don't ask me why - you'd think that with five-nines uptime 
> > guarantees you'd want fast bootup), and so you'll find large SCSI disks in 
> > particular with long spin-up times. In the laptop and desktop space I'd be 
> > very surprised to see anythign longer than a few seconds.
> 
> It's only a timeout. If you drives are fast, it will come up fast... if
> you drives are slow, it will come up slow, and if your drives are
> broken, you'll wait at most 31 seconds. Seems ok to me... It would be
> nicer in the long run if libata could resume asynchronously (by keeping
> the request queue blocked until full resume and polling the BUSY from a
> thread or a timer), but I don't think we should lower the timeout.

In reality it probably doesn't matter much, since everything will be
stalled until the queue is unfrozen anyways. Unless of course you have
several slow-to-resume devices so you would at least get some overlap.
But it would be nicer from a design view point.

-- 
Jens Axboe

Re: [git patch] libata resume fix

[Benjamin Herrenschmidt]

> In reality it probably doesn't matter much, since everything will be
> stalled until the queue is unfrozen anyways. Unless of course you have
> several slow-to-resume devices so you would at least get some overlap.
> But it would be nicer from a design view point.

In practice, it would be nice because most of X would restore while you
wait, it generally doesn't need the disk to do so unless you are heavy
on swap (or used suspend-to-disk :), that's one example among others...

At least letting other drivers restore in parallel, will improve things,
even if actual running of userland programs might still be stalled until
the disk kicks back in. But the whole experience of waking up the
machine will be improved from a black text screen waiting for the drive
to spin up ... :)

Ben.

Re: [git patch] libata resume fix

[Bill Davidsen]

Linus Torvalds wrote:
> 
> On Tue, 30 May 2006, Mark Lord wrote:
>> Not in a suspend/resume capable notebook, though.
>>
>> I don't know of *any* notebook drives that take longer
>> than perhaps five seconds to spin-up and accept commands.
>> Such a slow drive wouldn't really be tolerated by end-users,
>> which is why they don't exist.
> 
> Indeed. In fact, I'd be surprised to see it in a desktop too.
> 
> At least at one point, in order to get a M$ hw qualification (whatever 
> it's called - but every single hw manufacturer wants it, because some 
> vendors won't use your hardware if you don't have it), a laptop needed to 
> boot up in less than 30 seconds or something.
> 
> And that wasn't the disk spin-up time. That was the time until the Windows 
> desktop was visible.
> 
> Desktops could do a bit longer, and I think servers didn't have any time 
> limits, but the point is that selling a disk that takes a long time to 
> start working is actually not that easy. 
> 
> The market that has accepted slow bootup times is historically the server 
> market (don't ask me why - you'd think that with five-nines uptime 
> guarantees you'd want fast bootup), and so you'll find large SCSI disks in 
> particular with long spin-up times. In the laptop and desktop space I'd be 
> very surprised to see anythign longer than a few seconds.

The trade-off is that if I have a 15k rpm SCSI drive, it would take a 
lot of design changes to make it spin up quickly, and improve a function 
which is usually done on a server once every MTBF when replacing the 
failed unit.

I think the majority of very large or very fast drives are in systems 
which don't (deliberately) power cycles often, in rooms where heat is an 
issue. And to spin up quickly take a larger power supply... 30 sec is 
fine with most users.

Couldn't find a spin-up time for the new Seagate 750GB drive, but the 
seek sure is fast!

-- 
Bill Davidsen <davidsen@tmr.com>
   Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one errors occurs during
wildcard (glob) expansion.

Re: [git patch] libata resume fix

[Benjamin Herrenschmidt]

On Tue, 2006-05-30 at 09:22 -0400, Mark Lord wrote:
> Benjamin Herrenschmidt wrote:
> > On Sun, 2006-05-28 at 16:34 -0400, Jeff Garzik wrote:
> >> Please pull from 'upstream-fixes' branch of
> >> master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> >>
> >> to receive the following updates:
> >>
> >>  drivers/scsi/libata-core.c |    1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> Mark Lord:
> >>       the latest consensus libata resume fix
> > 
> > If your devices are coming from poweron-reset then you will have to wait
> > up to 31 seconds :( And yes, I _did_ have such a device at one point.
> 
> Not in a suspend/resume capable notebook, though.

Maybe, but 2 seconds is just "abitrary". I know some ATAPI devices (in
notebooks) that will drive the bus (and thus pollute whatever you try to
do) for way more than 2 seconds if they are reset with a CD in the
drive.

> I don't know of *any* notebook drives that take longer
> than perhaps five seconds to spin-up and accept commands.
> Such a slow drive wouldn't really be tolerated by end-users,
> which is why they don't exist.

They do, especially ATAPI.

> But I suppose people will want to suspend/resume bigger machines
> too, in which case a 10000rpm Raptor might need 15 seconds or so.
> 
> We could bump up the existing timeout, I suppose.
> 
> Perhaps Jeff could comment on any potential harm in libata
> for going all the way to 3100000 with the timeout?