Re: Back to the future.

From: Pavel Machek
Date: Thu May 03 2007 - 11:31:12 EST


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