On Wed, May 04, 2005 at 07:02:43PM -0700, Steve Langasek wrote: > > It also reduces the possibility of serious data corruption when suspending > > your machine and then booting with a non-resume-capable kernel. > > Reduces, but doesn't eliminate? How likely is it that such corruption will > happen? The new version of hibernate looks for swap devices with a software suspend header and invalidates the suspend image by mkswap'ing over it. It finds swap partitions and files okay in non-pathological cases (I believe exceptions include swap on LVM or encrypted using dm-crypt, both of which require substantial effort to use as suspend targets anyway; or if the partition isn't listed in /etc/fstab). The potential for data corruption comes in when you suspend (writing out an image containing all kernel data structures, including disc caches and filesystem meta data and so on), then boot a kernel not configured for resuming which mounts your filesystems read-write and starts writing to them (or even just replaying the journal), and then reboot again, resuming the saved image. Now the state of the filesystem on disc doesn't match the original kernel's idea of what should be there, and things go awry. While this is warned against in the suspend2 documentation, it still seems that people manage to do this every now and again - especially when setting up suspend for the first time and not setting the resume device correctly on the kernel command line or initrd. > Based on the available information, I'm not willing to accept a > newly-uploaded new upstream version into sarge. No problem. I certainly don't see the version in Sarge as being useless or unusable in any way. Cheers, Cameron.
Attachment:
signature.asc
Description: Digital signature