RFC: Self-snapshotting in Linux - Kernel

This is a discussion on RFC: Self-snapshotting in Linux - Kernel ; Sorry if this is a a crazy idea.....just be forewarned.... First, I would like to make a reference to VMWare's snapshot (name not important, emphasize the idea) feature - hopefully u are familiar with it. This is a feature whereby ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: RFC: Self-snapshotting in Linux

  1. RFC: Self-snapshotting in Linux

    Sorry if this is a a crazy idea.....just be forewarned....

    First, I would like to make a reference to VMWare's snapshot (name not
    important, emphasize the idea) feature - hopefully u are familiar with
    it. This is a feature whereby u can freeze the entire OS (kernel +
    userspace application running) and then later reload itself next time,
    continuing where it left off, without reboot from ground zero.

    Next, can I ask, is such a feature useful in Linux? Ie, able to
    restart the kernel + userspace application from where u left off, the
    last time round. Not JUST the normal suspend/resume feature, but
    more important able to CHOOSE among the different available images for
    u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
    save it, and then restore back the 2.6.23-rc5 image, work on it, save
    it, and then restore the previous image again. All done without
    virtualization as in the VMWare sense - which really is CPU intensive
    and slow things down a lot. Now we can directly execute each OS
    kernel image on the CPU, and since saving and restoring is quite fast
    (eg, zipping up the entire physical memory before saving into
    permanent storage) - I supposed this will be much faster than the
    normal initialization/fsck work done normally....or did I missed out
    anything?

    Essentially, to reiterate the key idea: able to snapshot the current
    kernel+userspace permanent.....restore from another snapshot....and
    then switch back again if needed etc.....will the implementation be
    difficult...if not impossible????

    --
    Regards,
    Peter Teoh
    --
    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/

  2. Re: RFC: Self-snapshotting in Linux

    Hibernation maybe ... try "echo "disk" > /sys/power/state"

    On Wed, Apr 16, 2008 at 4:44 PM, Peter Teoh wrote:
    > Sorry if this is a a crazy idea.....just be forewarned....
    >
    > First, I would like to make a reference to VMWare's snapshot (name not
    > important, emphasize the idea) feature - hopefully u are familiar with
    > it. This is a feature whereby u can freeze the entire OS (kernel +
    > userspace application running) and then later reload itself next time,
    > continuing where it left off, without reboot from ground zero.
    >
    > Next, can I ask, is such a feature useful in Linux? Ie, able to
    > restart the kernel + userspace application from where u left off, the
    > last time round. Not JUST the normal suspend/resume feature, but
    > more important able to CHOOSE among the different available images for
    > u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
    > save it, and then restore back the 2.6.23-rc5 image, work on it, save
    > it, and then restore the previous image again. All done without
    > virtualization as in the VMWare sense - which really is CPU intensive
    > and slow things down a lot. Now we can directly execute each OS
    > kernel image on the CPU, and since saving and restoring is quite fast
    > (eg, zipping up the entire physical memory before saving into
    > permanent storage) - I supposed this will be much faster than the
    > normal initialization/fsck work done normally....or did I missed out
    > anything?
    >
    > Essentially, to reiterate the key idea: able to snapshot the current
    > kernel+userspace permanent.....restore from another snapshot....and
    > then switch back again if needed etc.....will the implementation be
    > difficult...if not impossible????
    >
    > --
    > Regards,
    > Peter Teoh
    > --
    > 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/
    >




    --
    Cheers
    - eric
    --
    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/

  3. Re: RFC: Self-snapshotting in Linux


    On Wed, 2008-04-16 at 16:44 +0800, Peter Teoh wrote:
    > Essentially, to reiterate the key idea: able to snapshot the current
    > kernel+userspace permanent.....restore from another snapshot....and
    > then switch back again if needed etc.....will the implementation be
    > difficult...if not impossible????
    >


    As I see it the main thing is that VMWare doesn't have to worry about
    trying to put hardware in to (and pull out of) low power modes. VMWare
    hardware is never left in an undefined state by poorly written drivers
    etc.

    I think hibernation is about what you want; snapshotting as you describe
    it should fall down for about the same reasons :-)

    --Ben.
    --
    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/

  4. Re: RFC: Self-snapshotting in Linux

    Peter Teoh wrote:
    > Sorry if this is a a crazy idea.....just be forewarned....
    >
    > First, I would like to make a reference to VMWare's snapshot (name not
    > important, emphasize the idea) feature - hopefully u are familiar with
    > it. This is a feature whereby u can freeze the entire OS (kernel +
    > userspace application running) and then later reload itself next time,
    > continuing where it left off, without reboot from ground zero.
    >
    > Next, can I ask, is such a feature useful in Linux? Ie, able to
    > restart the kernel + userspace application from where u left off, the
    > last time round. Not JUST the normal suspend/resume feature, but
    > more important able to CHOOSE among the different available images for
    > u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
    > save it, and then restore back the 2.6.23-rc5 image, work on it, save
    > it, and then restore the previous image again. All done without
    > virtualization as in the VMWare sense - which really is CPU intensive
    > and slow things down a lot. Now we can directly execute each OS
    > kernel image on the CPU, and since saving and restoring is quite fast
    > (eg, zipping up the entire physical memory before saving into
    > permanent storage) - I supposed this will be much faster than the
    > normal initialization/fsck work done normally....or did I missed out
    > anything?
    >
    > Essentially, to reiterate the key idea: able to snapshot the current
    > kernel+userspace permanent.....restore from another snapshot....and
    > then switch back again if needed etc.....will the implementation be
    > difficult...if not impossible????
    >
    >

    Hrm... well, the kernel has the ability since 2.6.20 (although its in
    testing AFAIK) to relocate itself on a crash. Reference:


    Relocatable kernel support for x86

    This feature (enabled with CONFIG_RELOCATABLE) isn't very noticeable for
    end-users but it's quite interesting from a kernel POV. Until now, it
    was a requirement that a i386 kernel was loaded at a fixed memory
    address in order to work, loading it in a different place wouldn't work.
    This feature allows to compile a kernel that can be loaded at different
    4K-aligned addresses, but always below 1 GB, with no runtime overhead.
    Kdump users (a feature introduced in 2.6.13
    that triggers kexec
    in a kernel crash in order to boot a
    kernel that has been previously loaded at an 'empty' address, then runs
    that kernel, saves the memory where the crashed kernel was placed, dumps
    it in a file and continues booting the system) will benefit from this
    because until now the "rescue kernel" needed to be compiled with
    different configuration options in order to make it bootable at a
    different address. With a relocatable kernel, the same kernel can be
    booted at different addresses. (commit 1
    ,
    2
    ,
    3
    ,
    4)




    Maybe you load up another kernel to handle the snapshot, and then hand
    the system back to it afterwards? What do you think?


  5. Re: RFC: Self-snapshotting in Linux

    > Sorry if this is a a crazy idea.....just be forewarned....
    >
    > First, I would like to make a reference to VMWare's snapshot (name not
    > important, emphasize the idea) feature - hopefully u are familiar with
    > it. This is a feature whereby u can freeze the entire OS (kernel +
    > userspace application running) and then later reload itself next time,
    > continuing where it left off, without reboot from ground zero.
    >
    > Next, can I ask, is such a feature useful in Linux? Ie, able to
    > restart the kernel + userspace application from where u left off, the
    > last time round. Not JUST the normal suspend/resume feature, but
    > more important able to CHOOSE among the different available images
    > for
    > u to resume on. Eg, u want to freeze the current 2.6.25-rc6
    > kernel,


    Could we use english on this list?

    Anyway, hibernate, cp /dev/root /somewhere/root.1; cp /dev/swap
    /somewhere/swap.1

    If you want to resume selected version, copy back that set of devices,
    and proceed normally.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/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/

  6. Re: RFC: Self-snapshotting in Linux

    On Wed, Apr 16, 2008 at 4:44 AM, Peter Teoh wrote:
    > Sorry if this is a a crazy idea.....just be forewarned....
    >
    > First, I would like to make a reference to VMWare's snapshot (name not
    > important, emphasize the idea) feature - hopefully u are familiar with
    > it. This is a feature whereby u can freeze the entire OS (kernel +
    > userspace application running) and then later reload itself next time,
    > continuing where it left off, without reboot from ground zero.
    >
    > Next, can I ask, is such a feature useful in Linux? Ie, able to
    > restart the kernel + userspace application from where u left off, the
    > last time round. Not JUST the normal suspend/resume feature, but
    > more important able to CHOOSE among the different available images for
    > u to resume on. Eg, u want to freeze the current 2.6.25-rc6 kernel,
    > save it, and then restore back the 2.6.23-rc5 image, work on it, save
    > it, and then restore the previous image again. All done without
    > virtualization as in the VMWare sense - which really is CPU intensive
    > and slow things down a lot. Now we can directly execute each OS
    > kernel image on the CPU, and since saving and restoring is quite fast
    > (eg, zipping up the entire physical memory before saving into
    > permanent storage) - I supposed this will be much faster than the
    > normal initialization/fsck work done normally....or did I missed out
    > anything?
    >
    > Essentially, to reiterate the key idea: able to snapshot the current
    > kernel+userspace permanent.....restore from another snapshot....and
    > then switch back again if needed etc.....will the implementation be
    > difficult...if not impossible????
    >
    > --
    > Regards,
    > Peter Teoh


    By using LVM-2 snapshots you can already do this with data drives.

    So if you setup a XEN setup where the DomU boot drives are Dom0 LVs
    you should be golden.

    Ie. from Dom0 you can create/restore your snapshots of your DomU instances.

    It may also be possible to make LVM snapshots work with the root
    partition of the physical boot drive, but that would take initrd magic
    I have never tried.

    Greg
    --
    Greg Freemyer
    Litigation Triage Solutions Specialist
    http://www.linkedin.com/in/gregfreemyer
    First 99 Days Litigation White Paper -
    http://www.norcrossgroup.com/forms/w...whitepaper.pdf

    The Norcross Group
    The Intersection of Evidence & Technology
    http://www.norcrossgroup.com
    --
    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/

  7. Re: RFC: Self-snapshotting in Linux

    On Wed 2008-04-16 23:21:05, Peter Teoh wrote:
    > Thank you for your reply.
    >
    > Just some questions...
    >
    > On 4/16/08, Pavel Machek wrote:
    > > > Sorry if this is a a crazy idea.....just be forewarned....
    > > >
    > > > First, I would like to make a reference to VMWare's snapshot (name not
    > > > important, emphasize the idea) feature - hopefully u are familiar with
    > > > it. This is a feature whereby u can freeze the entire OS (kernel +
    > > > userspace application running) and then later reload itself next time,
    > > > continuing where it left off, without reboot from ground zero.
    > > >
    > > > Next, can I ask, is such a feature useful in Linux? Ie, able to
    > > > restart the kernel + userspace application from where u left off, the
    > > > last time round. Not JUST the normal suspend/resume feature, but
    > > > more important able to CHOOSE among the different available images
    > > > for
    > > > u to resume on. Eg, u want to freeze the current 2.6.25-rc6
    > > > kernel,

    > >
    > >
    > > Could we use english on this list?
    > >
    > > Anyway, hibernate, cp /dev/root /somewhere/root.1; cp /dev/swap
    > > /somewhere/swap.1
    > >

    >
    > The current userspace suspend actually saved the entire state of the
    > memory (which applications are oepne/closed) into the swap area,
    > right?


    > So the 2nd line above of backingup the swap should allow us to restore
    > back state of the userspace applications later - correct?


    Yes, but you need to match memory state with filesystem state...
    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/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/

+ Reply to Thread