Summary: Re: Spin down HDD after disk sync or before power off

[Alexander Best]

On Fri Oct 22 10, Alexander Motin wrote:
> Alexander Best wrote:
> > the current implementation (kern.cam.power_down) uses a singe "sleep"
> > operation, whereas the patch by oliver uses "flush" and "standby immediate".
> 
> Sleep is just more aggressive. It puts device into deeper sleep state. I
> don't think it is important from wearing point of view.
> 
> > unfortunately almost nobody was aware of mav's work at the time of the
> > discussion. would have been nice to have a note in cam(4) explaining the
> > purpose of kern.cam.power_down. that way a lot of double work could have been
> > avoided.
> 
> That code was expected to handle spindown on shutdown in unified fashion
> for ATA and SCSI devices without dependency from peripheral driver (even
> without one), just using different commands for each protocol. It works,
> but in current implementation it is unreliable. The problem is that it
> uses polled operation mode, not supported by some controllers or
> unreliable on some (e.g. atapicam). So the code is disabled now by
> default. I haven't yet decided it's future: it should be either reworked
> or reverted.

so how about olivers patch? it will only apply to ata devices so it's
garanteed not to break any other CAM devices (i'm thinking about the aac
controller issue). you could revert your previous shutdown work and plug
olivers patch into CAM. you might want to replace the combination of
flush/standby immediate with sleep.

cheers.
alex

> 
> As positive side -- as soon as CAM is not using NewBus at the moment,
> CAM registers own shutdown handlers. That allows CAM to receive the
> howto argument, which allows to separate cases of reboot and shutdown
> cases just by:
> 	if ((howto & RB_POWEROFF) == 0)
> 
> > is the ATA(4) subsystem still being actively worked on or will it die out after
> > officially switching to ATA_CAM? the question is, if it is worth implementing
> > hdd spin down for ATA(4)?
> 
> I don't think it will be really critical. Next months I am going to work
> on ataraid(4) replacement, which was main declared show stopper for the
> switch. I hope to trash legacy code some time after switching to ATA_CAM
> to clear number of odd things (like almost not working port multipliers
> support or duplicate drivers), required by it.
> 
> -- 
> Alexander Motin

-- 
a13x