Do we need to implement sr START/STOP management

Do we need to implement sr START/STOP management

[JiSheng Zhang]

Hi List,

Currently, there's no start/stop management in scsi cdrom driver to
spin up/down the motor do we need to implement it?

Thanks in advance,
Jisheng

Re: Do we need to implement sr START/STOP management

[James Bottomley]

On Tue, 2011-11-01 at 13:31 +0800, JiSheng Zhang wrote:
> Currently, there's no start/stop management in scsi cdrom driver to
> spin up/down the motor do we need to implement it?

Say more ... like what you think it buys.  The auto spin down of a CD
tends to be the best power control we have and it's not even clear that
manufacturers have implemented any other useful power states.

James

Re: Do we need to implement sr START/STOP management

[JiSheng Zhang]

Hi James,

2011/11/1 James Bottomley <James.Bottomley@hansenpartnership.com>:
> On Tue, 2011-11-01 at 13:31 +0800, JiSheng Zhang wrote:
>> Currently, there's no start/stop management in scsi cdrom driver to
>> spin up/down the motor do we need to implement it?
>
> Say more ... like what you think it buys.  The auto spin down of a CD
> tends to be the best power control we have and it's not even clear that
> manufacturers have implemented any other useful power states.

Does it mean the behavior depends on manufacturers? Some cd will spin
down automatically? Even so, how about during shutdown just after reading
something from cdrom?

Thanks,
Jisheng

Re: Do we need to implement sr START/STOP management

[James Bottomley]

On Tue, 2011-11-01 at 14:35 +0800, JiSheng Zhang wrote:
> 2011/11/1 James Bottomley <James.Bottomley@hansenpartnership.com>:
> > On Tue, 2011-11-01 at 13:31 +0800, JiSheng Zhang wrote:
> >> Currently, there's no start/stop management in scsi cdrom driver to
> >> spin up/down the motor do we need to implement it?
> >
> > Say more ... like what you think it buys.  The auto spin down of a CD
> > tends to be the best power control we have and it's not even clear that
> > manufacturers have implemented any other useful power states.
> 
> Does it mean the behavior depends on manufacturers? Some cd will spin
> down automatically?

All CDs spin down when not reading (or burning) since the motor power is
pretty high.  Most also do speed adjustments on the fly as well to try
to match platter speed and read or burn rate.

>  Even so, how about during shutdown just after reading
> something from cdrom?

What's the use case?  For internal CDs, shutdown removes power anyway.

James

Re: Do we need to implement sr START/STOP management

[Robert Hancock]

On 11/01/2011 12:35 AM, JiSheng Zhang wrote:
> Hi James,
>
> 2011/11/1 James Bottomley<James.Bottomley@hansenpartnership.com>:
>> On Tue, 2011-11-01 at 13:31 +0800, JiSheng Zhang wrote:
>>> Currently, there's no start/stop management in scsi cdrom driver to
>>> spin up/down the motor do we need to implement it?
>>
>> Say more ... like what you think it buys.  The auto spin down of a CD
>> tends to be the best power control we have and it's not even clear that
>> manufacturers have implemented any other useful power states.
>
> Does it mean the behavior depends on manufacturers? Some cd will spin
> down automatically? Even so, how about during shutdown just after reading
> something from cdrom?
>
> Thanks,
> Jisheng

I believe the main reason disks are stopped during shutdown is that for 
many hard drives that use head unloading, it's much better for the 
lifespan of the drive to do a powered head unload on software command 
before powering off than an emergency unload caused by a loss of power. 
I don't believe that optical drives have such an issue.

Re: Do we need to implement sr START/STOP management

[JiSheng Zhang]

Hello,

2011/11/2 Robert Hancock <hancockrwd@gmail.com>:
> On 11/01/2011 12:35 AM, JiSheng Zhang wrote:
>>
> I believe the main reason disks are stopped during shutdown is that for many
> hard drives that use head unloading, it's much better for the lifespan of
> the drive to do a powered head unload on software command before powering
> off than an emergency unload caused by a loss of power. I don't believe that
> optical drives have such an issue.
>
I have talked with one cdrom firmware engineer, cdrom also need to put
the head at
"park" position. So we also need to let cdrom spin down when poweroff,
suspend etc for lifespan?

Assume /sbin/shutdown immediately after reading from cdrom and cdrom
has no time to spin down

Thanks,
Jisheng

Re: Do we need to implement sr START/STOP management

[Tejun Heo]

Hello,

On Wed, Nov 2, 2011 at 11:38 PM, JiSheng Zhang <jszhang3@gmail.com> wrote:
> I have talked with one cdrom firmware engineer, cdrom also need to put
> the head at
> "park" position. So we also need to let cdrom spin down when poweroff,
> suspend etc for lifespan?

I'm pretty skeptical that's necessary, and here's what we should do
regarding ATAPI devices.

  Do what Windows does.

In many cases, manufacturers are verifying only against windows and
deviation from windows behavior usually means trouble regardless of
the standard. Even sending TURs repeatedly can send devices into
complete lockup. So, I don't really care what the standard says. If
windows isn't issuing spindown on shutdown, we shouldn't either. The
only thing we would be achieving is to cause timeouts, retrials and
device detach before the system eventually can turn itself off.

Thanks.

-- 
tejun

Re: Do we need to implement sr START/STOP management

[Douglas Gilbert]

On 11-11-03 10:38 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 2, 2011 at 11:38 PM, JiSheng Zhang<jszhang3@gmail.com>  wrote:
>> I have talked with one cdrom firmware engineer, cdrom also need to put
>> the head at
>> "park" position. So we also need to let cdrom spin down when poweroff,
>> suspend etc for lifespan?
>
> I'm pretty skeptical that's necessary, and here's what we should do
> regarding ATAPI devices.
>
>    Do what Windows does.
>
> In many cases, manufacturers are verifying only against windows and
> deviation from windows behavior usually means trouble regardless of
> the standard. Even sending TURs repeatedly can send devices into
> complete lockup. So, I don't really care what the standard says. If

That's a pretty poor attitude. I suspect Microsoft care. If so they
would be transitioning away from TEST UNIT READY to REQUEST SENSE
to monitor power conditions and the progress indication.

In the latest MMC draft (mmc6r02g.pdf 20091211), monitoring based on
the TEST UNIT READY command is typically followed by this rider:
"This behavior is not recommended"!

Doug Gilbert

Re: Do we need to implement sr START/STOP management

[Tejun Heo]

On Thu, Nov 3, 2011 at 8:34 AM, Douglas Gilbert <dgilbert@interlog.com> wrote:
> That's a pretty poor attitude. I suspect Microsoft care. If so they
> would be transitioning away from TEST UNIT READY to REQUEST SENSE
> to monitor power conditions and the progress indication.

I was talking about media presence polling.  We used to include TUR in
the sequence and there have been some number of devices which worked
fine for a while but lock up eventually.  Windows only issues
CHECK_MEDIA_EVENT_STATUS so nobody has tested extended TUR cycles and
nobody is fixing an optical drive EOL'd six months ago either, so what
I or you think or feel doesn't matter in the end.  The most important
thing is we provide drivers which allow proper operation and, sadly,
at this point, the best way to get there is following what windows
does.  It's not like we lose any functionality that way anyway.

If windows isn't spinning down the drive, it is highly unlikely that
missing that harms anything and it's highly like there are a bunch of
devices which would go "uh... what the hell is this? I don't know
this. osidfjalekjalkgjs".  So, there simply is no point at all.

Thanks.

-- 
tejun

Re: Do we need to implement sr START/STOP management

[Douglas Gilbert]

On 11-11-03 11:46 AM, Tejun Heo wrote:
> On Thu, Nov 3, 2011 at 8:34 AM, Douglas Gilbert<dgilbert@interlog.com>  wrote:
>> That's a pretty poor attitude. I suspect Microsoft care. If so they
>> would be transitioning away from TEST UNIT READY to REQUEST SENSE
>> to monitor power conditions and the progress indication.
>
> I was talking about media presence polling.  We used to include TUR in
> the sequence and there have been some number of devices which worked
> fine for a while but lock up eventually.  Windows only issues
> CHECK_MEDIA_EVENT_STATUS so nobody has tested extended TUR cycles and

Do you mean the GET EVENT STATUS NOTIFICATION command (as there is
no CHECK MEDIA EVENT STATUS command in SCSI or ATA)? If so it is
one of the "good guys" along with the REQUEST SENSE command. And
as I said TUR is not recommended. So looking at MS usage _and_
the standards is a useful guide.


BTW The REQUEST SENSE implemented in the libata's SAT layer is
completely broken (and has been since day one). Is anyone planning
to fix it? An LSI SAS HBA with recent firmware and accessing a
SATA disk is a pretty good example of what a compliant SAT layer
looks like.

> nobody is fixing an optical drive EOL'd six months ago either, so what
> I or you think or feel doesn't matter in the end.  The most important
> thing is we provide drivers which allow proper operation and, sadly,
> at this point, the best way to get there is following what windows
> does.  It's not like we lose any functionality that way anyway.
>
> If windows isn't spinning down the drive, it is highly unlikely that
> missing that harms anything and it's highly like there are a bunch of
> devices which would go "uh... what the hell is this? I don't know
> this. osidfjalekjalkgjs".  So, there simply is no point at all.

I agree. SCSI and ATA define idle states (with some fuzziness in
the naming) that have timers associated with them. Those
mechanisms seem to work pretty well without the intervention of
commands like START STOP UNIT.

Doug Gilbert

Re: Do we need to implement sr START/STOP management

[Tejun Heo]

Hello,

On Thu, Nov 03, 2011 at 01:13:16PM -0400, Douglas Gilbert wrote:
> Do you mean the GET EVENT STATUS NOTIFICATION command (as there is
> no CHECK MEDIA EVENT STATUS command in SCSI or ATA)? If so it is
> one of the "good guys" along with the REQUEST SENSE command. And
> as I said TUR is not recommended. So looking at MS usage _and_
> the standards is a useful guide.

Yes, that's the one.  Sorry, I always get confused about its name.
IIRC, it's a relatively new command, right?  Anyways, I'm not arguing
standards are useless but that actual usages have to take precedence.

> I agree. SCSI and ATA define idle states (with some fuzziness in
> the naming) that have timers associated with them. Those
> mechanisms seem to work pretty well without the intervention of
> commands like START STOP UNIT.

Cool, thanks.

-- 
tejun