[lkml]   [2007]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Back to the future.
    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).

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-04-28 12:35    [W:0.049 / U:17.028 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site