[Suspend2-devel] Re: [ltp] [PATCH] 2.6.17: Unload disks heads before powering down

[Nigel Cunningham]

Hi.

On Tue, 2006-09-26 at 14:52 -0300, Henrique de Moraes Holschuh wrote:
> > >The EH suspend subroutine does a STANDBY IMMEDIATE command, and that
> > >flushes caches and spins down the disk, which IS the right thing to do on
> > >a system shutdown, but quite less so for a system reset.
> > 
> > Any real drawback to doing an UNLOAD IMMEDIATE instead of STANDBY
> > IMMEDIATE?
> 
> Is Unload Immediate widely supported?
> 
> > >> Any idea where that comes from, and how it relates to the SuSE head
> > >> unload patch?
> > 
> > >If you shutdown the scsi bus, the unload patch will spin down the disk.
> > 
> > I'm getting a spindown on reboot (i.e., shutdown) even without the SuSE
> > patch.
> 
> Check the userspace scripts too.  They may be doing it (get rid of hdparm
> and userspace won't spin down disks anymore).  Add some printk on libata-eh
> (2.6.18) to track down when *_eh_suspend is called...
> 
> > devices in order to write the snapshot to disk. Currently this causes a
> > disk spin-down and spin-up, which is bad for the disk and bad for suspend
> > time.
> > 
> > >I suspect the "so don't do it" finale for this thought is only possible
> > >with 2.6.18,
> > 
> > What changed here in 2.6.18?  I've tested with vanilla 2.6.18, with
> > 2.6.17.4+suspend2-2.2.7.1 and with 2.6.17.13+suspend2-2.2.7.6.
> 
> 2.6.18 has the new Linus way of doing PM, AFAIK.  Not to mention the
> entirely new libata EH path.
> 
> > >Suspend2 2.2.8 + kernel 2.6.18 is corrupting the page cache here, do
> > >*not* use it if you value your data.
> > 
> > Does it?! During suspend, you mean? I was just about to test that...
> 
> Well, it happened after resume from disk.  I have filled a bug about it
> already.  I get absolutely no corruption whatsoever from S3 (without
> suspend2 patches).
> 
> I have seen suspend2 S3 corruption (I don't recall if there were S4
> corruptions as well) with 2.6.17, but it was a silent corruption that
> eventually caused ext3 to go berserk.  I don't have a working suspend2
> system (S3 or S4) since 2.6.16 days.

That seems really strange, but Suspend2 hardly makes any changes that
would affect suspend to ram without suspending to disk. They'd all be in
kernel/power/process.c, and those changes revolve around making the
freezer quieter and freezing bdevs to make the filesystem data more
consistent and ensure activity really is stopped. Perhaps this is the
fruit of the same regression others are seeing with 2.6.18, and Suspend2
is getting hit because it's using bdev freezing and the vanilla kernel
doesn't.

Regards,

Nigel