Messages in this thread | | | Date | Thu, 26 Apr 2007 01:13:19 +0200 | From | Pavel Machek <> | Subject | Re: suspend2 merge (was Re: [Suspend2-devel] Re: CFS and suspend2: hang in atomic copy) |
| |
Hi!
> > > And name *one* thing that have in common. > > > > Set/reset the scsi transaction id thingy? Hibernation didn't work with > > SCSI for a long time precisely because that support was missing. > > And by "hibernation", you mean what? You mean "snapshot + shutdown", > right? > > Think about it for five seconds, and then ask yourself: at which point in > the "snapshot + shutdown" sequence would you actually tell a disk to shut > down?
Current design is:
Twice. Once during snapshot (then we spin it up when the snapshot is done), and once during shutdown.
Yep, we optimize away spindown, because it takes too long, so SCSI disks are actually very bad example.
> If you said "snapshot", then you'd be *wrong*. > > That's my _point_. The snapshot() function should not (and MUST NOT) tell > disks to shut down, because unlike suspend(), we're still going to _use_ > those disks afterwards (why? To write out the snapshot image!).
No, I'd like you to understand that we actually CAN tell the disks to spin down, because we'll call resume and spin them back again before writing the image. We used to do it. We still can do it, but it is slow.
Yes, it is quite confusing. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |