Re: Back to the future.

[Rafael J. Wysocki]

On Friday, 27 April 2007 12:12, Pekka J Enberg wrote:
> Am Freitag, 27. April 2007 08:18 schrieb Pekka J Enberg:
> > > No. The snapshot is just that. A snapshot in time. From kernel point of 
> > > view, it doesn't matter one bit what when you did it or if the state has 
> > > changed before you resume. It's up to userspace to make sure the user 
> > > doesn't do real work while the snapshot is being written to disk and 
> > > machine is shut down.
> 
> On Fri, 27 Apr 2007, Oliver Neukum wrote:
> > And where is the benefit in that? How is such user space freezing logic
> > simpler than having the kernel do the write?
> >
> > What can you do in user space if all filesystems are r/o that is worth the
> > hassle?
> 
> I am talking about snapshot_system() here. It's not given that the 
> filesystems need to be read-only (you can snapshot them too). The benefit 
> here is that you can do whatever you want with the snapshot (encrypt, 
> compress, send over the network)  and have a clean well-defined interface 
> in the kernel. In addition, aborting the snapshot is simpler, simply 
> munmap() the snapshot.

Well, swsusp currently does almost the same, except that you can read the
image from the kernel as a stream of bytes, using read() and, during the
restore phase, upload the same image using write().  The advantage of this
is that the interface is symmetrical from the user space's point of view.
[You're cancelling the hibernation by closing /dev/snapshot, which also is
quite natural.]

If you look at the interface in user.c, there are only two ioctls really needed
for that in there, SNAPSHOT_ATOMIC_SNAPSHOT and
SNAPSHOT_ATOMIC_RESTORE.  Two more are handy for freezing
tasks, SNAPSHOT_FREEZE and SNAPSHOT_UNFREEZE.  The others were added
later, to make the user space part simpler or capable of doing some fancy
stuff, which I am ready to admit was a mistake.

> The problem with writing in the kernel is obvious: we need to add new code 
> to the kernel for compression, encryption, and userspace interaction 
> (graphical progress bar) that are important for user experience.

Yes, and that's why we wanted to introduce the userland part.  The problem
with this approach, as it's turned out, is that the userland part must be a
very specialized piece of software, really careful of what it's doing, mainly
because of the inability to checkpoint filesystems.  If we could checkpoint
filesystems and were able to unfreeze the user space after creating the
snapshot without the risk of corrupting filesystems in the restore phase,
the userland part could be much simpler (even as simple as Linus suggested).

Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/