On Tue, 2007-05-15 at 17:34 +0200, Tejun Heo wrote: > Hello, Scott. > Hi, Thanks for your quick reply!
> > Secondly, we've never attempted any workarounds for libata. Our > > halt/reboot only iterates /proc/ide, which should be empty for > > libata-based systems - therefore we've never issued FLUSH CACHE or > > STANDBYNOW on libata drives from userspace. > > > > In this case, how should we proceed? > > > > * Check whether /sys/modules/libata/parameters/spindown_compat exists. > > If it does, write 0 to it. > > > > Since we've never been broken, can we not arrange for this to be always > > zero? Perhaps just writing to it on boot? > > Yes, you can clear that node anytime you want and if your shutdown > utilities don't issues FLUSH and STANDBY for libata disks on shutdown, > that's the only thing you'll need to do. This is still in discussion > but you might not have to do even that. Please read the following > thread. > > http://article.gmane.org/gmane.linux.ide/18846 > > I'll update you when things are determined. It might be that you > don't have to do anything. Sorry about the fuss. > That's no problem, it's good to finally get this stuff cleaned up a little. We have an inherent preference for the cleanest and simplest implementation, obviously :-) If that means no userspace code, and just call reboot(), WIN! > > For each libata harddisk > > > > * Check whether /sys/class/scsi_disk/h:c:i:l/manage_start_stop > > exists. If it doesn't, synchronize cache and spin the disk down > > as before. If it does, do nothing and continue to the next disk. > > The file is also accessible > > as /sys/block/sdX/device/scsi_disk:*/manage_start_stop. > > > > What's the reason for needing to flush the cache and standby the disk by > > hand? What are the circumstances where the manage_start_stop will not > > exist? > > On all kernels upto 2.6.21, libata doesn't issue STANDBYNOW on > shutdown, so some distros including Debian do it during userland > shutdown. This isn't a complete solution but most disks don't spin up > on the following kernel FLUSH, so it's better than not doing anything > which results in emergency unload for all disks. > Since we've been running with 2.6.x and libata for a while, without bothering to do this, is there any harm in continuing to not do this? It's obviously not a regression for us, and we can answer "upgrade to 7.10" quite cheerfully if it turns out there are people with bugs (which they will have always had). I'll keep an eye on the thread you linked to, if we don't even need to write any zeros, we're definitely happy people :-) Scott -- Scott James Remnant Ubuntu Development Manager [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
