On Sun, Dec 05, 2010 at 01:49:25PM +0000, Dr. David Alan Gilbert wrote:
> * Rafael J. Wysocki (rjw@xxxxxxx) wrote:
> > On Saturday, December 04, 2010, Dr. David Alan Gilbert wrote:
> > > * Rafael J. Wysocki (rjw@xxxxxxx) wrote:
>
> <snip>
>
> > > >
> > > > Well, I had no idea it would cause any problems to happen for any user space.
> > > > That is an internal kernel thing.
> > >
> > > Well it's a signature on a device, so hardly internal.
> >
> > Only the kernel uses it, though.
>
> Except the blkid currently looks in the space where this new signature
> lives to try and figure out what type of partition it is, and hence where to find
> it's uuid.
It's not about UUID only. We need to know that the device is swap
area, suspend data, filesystem, raid, ... all this is gathered by udev,
used in udev rules and distributed to many places in system (desktop
UI, ...).
> > > Hmm, but what's the expected behaviour after a failed resume from hibernate?
> > > Surely someone shouldn't have to run mkswap to fix up their system after a trivial
> > > failure like that?
> >
> > That's a problem with the kernel's built-in hibernation. The original signature
> > should be restored automatically by the kernel in such cases, but there were
> > problems with users who started a wrong kernel to resume and then wanted
> > to repreat that without losing the image. I'm not sure if that's a valid reason
> > to avoid restoring the signature, though. Anyway, s2disk handles that
> > correctly I believe.
swapon(8) cares about sw suspend data (for years), it automatically
calls mkswap if sw suspend data are detected on the device.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
