* Re: [git patch] libata resume fix
2006-05-30 18:26 ` Linus Torvalds
@ 2006-05-30 18:40 ` Ric Wheeler
2006-05-30 22:37 ` Benjamin Herrenschmidt
2006-05-31 22:01 ` Bill Davidsen
2 siblings, 0 replies; 10+ messages in thread
From: Ric Wheeler @ 2006-05-30 18:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Lord, Benjamin Herrenschmidt, Jeff Garzik, Andrew Morton,
linux-ide, linux-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [git patch] libata resume fix
2006-05-30 18:26 ` Linus Torvalds
2006-05-30 18:40 ` Ric Wheeler
@ 2006-05-30 22:37 ` Benjamin Herrenschmidt
2006-05-31 6:47 ` Jens Axboe
2006-05-31 22:01 ` Bill Davidsen
2 siblings, 1 reply; 10+ messages in thread
From: Benjamin Herrenschmidt @ 2006-05-30 22:37 UTC (permalink / raw)
To: Linus Torvalds
Cc: Mark Lord, Jeff Garzik, Andrew Morton, linux-ide, linux-kernel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [git patch] libata resume fix
2006-05-30 22:37 ` Benjamin Herrenschmidt
@ 2006-05-31 6:47 ` Jens Axboe
2006-05-31 6:56 ` Benjamin Herrenschmidt
0 siblings, 1 reply; 10+ messages in thread
From: Jens Axboe @ 2006-05-31 6:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Linus Torvalds, Mark Lord, Jeff Garzik, Andrew Morton, linux-ide,
linux-kernel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [git patch] libata resume fix
2006-05-31 6:47 ` Jens Axboe
@ 2006-05-31 6:56 ` Benjamin Herrenschmidt
0 siblings, 0 replies; 10+ messages in thread
From: Benjamin Herrenschmidt @ 2006-05-31 6:56 UTC (permalink / raw)
To: Jens Axboe
Cc: Linus Torvalds, Mark Lord, Jeff Garzik, Andrew Morton, linux-ide,
linux-kernel
> 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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [git patch] libata resume fix
2006-05-30 18:26 ` Linus Torvalds
2006-05-30 18:40 ` Ric Wheeler
2006-05-30 22:37 ` Benjamin Herrenschmidt
@ 2006-05-31 22:01 ` Bill Davidsen
2 siblings, 0 replies; 10+ messages in thread
From: Bill Davidsen @ 2006-05-31 22:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Benjamin Herrenschmidt, Jeff Garzik, Andrew Morton, linux-ide,
linux-kernel
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.
^ permalink raw reply [flat|nested] 10+ messages in thread