Henrique de Moraes Holschuh wrote: > Well, the reason I raised the ruckus in the first place was just the > emergency unload, yes. I didn't know about any missing cache flushes (and > AFAIK we never had any reported to us). We will have to fix that in halt(8) > IMHO, just in case. And probably hdparm/sdparm should also know to not > standby or sleep disks without a cache flush, either. > > I also don't know the history of halt(8), Miquel does... so I have not much > else to comment. OIC, hmm.. STANDBYNOW for cache flushing. Interesting. > At least now it is clear what we need halt(8) to do (in Debian, anyway): > > 1. check if we have a responsible kernel or not through sysfs. > > 1a: kernel is responsible, and can spin down disks at shutdown > > - if given -h on command line, use sysfs to tell kernel > to spin down *all* disk devices we can find in sysfs, > and don't send any taskfiles or IOCTLs to the disks. > > 1b: kernel is missing this essential feature > > - keep doing what we are doing now, but issue a cache > flush before we send any standby commands. > > 2. push that to Debian unstable, and also to stable-proposed-updates, or at > the very least to backports.org. > > This will give maximum compatibility with the kernel, and fix the > cache-not-flushed-before-spindown issue. Yeap, right. It would be great if you can push the updates upstream so that other distros can use it too. Also, some configurations might prefer halt not touching the sysfs nodes so that the user can configure mange_start_stop, but I guess that kind of stuff is up to distro. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
