Re: Back to the future.

[Pavel Machek <pavel@ucw.cz>]

Hi!

> >>It makes it harder to debug (wouldn't it be *nice* to 
> >>just ssh in,  and do
> >>	gdb -p <snapshotter>
> >
> >Make the machine being suspended a VM and you can 
> >already do that.
> 
> >>when something goes wrong?) but we also *depend* on 
> >>user space for  various things (the same way we depend 
> >>on kernel threads, and why  it has been such a total 
> >>disaster to try to freeze the kernel  threads too!). 
> >>For example, if you want to do graphical stuff,  just 
> >>using X would be quite nice,  wouldn't it?
> >
> >But in doing so you make the contents of the disk 
> >inconsistent with  the state you've just snapshotted, 
> >leading to filesystem  corruption. Even if you modify 
> >filesystems to do checkpointing  (which is what we're 
> >really talking about), you still also have the  problem 
> >that your snapshot has to be stored somewhere before 
> >you  write it to disk, so you also have to either [snip]
> 
> Actually, it's a lot simpler than that.  We can just 
> combine the  device-mapper snapshot with a VM+kernel 
> snapshot system call and be  almost done:
> 
>   sys_snapshot(dev_t snapblockdev, int __user 
>   *snapshotfd);
> 
> When sys_snapshot is run, the kernel does:
> 
> 1)  Sequentially freeze mounted filesystems using 
> blockdev freezing.   If it's an fs that doesn't support 
> freezing then either fail or force- remount-ro that fs 
> and downgrade all its filedescriptors to RO.   Doesn't 
> need extra locking since process which try to do IO 
> either  succeed before the freeze call returns for that 
> blockdev or sleep on  the unfreeze of that blockdev.  
> Filesystems are synchronized and made  clean.

How mature is freezing filesystems -- will it work on at least ext2/3
and vfat?

What happens if you try to boot and filesystems are frozen from
previous run?

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html