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
On May 03, 2007, at 11:10:47, Pavel Machek wrote:
> How mature is freezing filesystems -- will it work on at least
> ext2/3 and vfat?
I'm pretty sure it works on ext2/3 and xfs and possibly others, I
don't know either way about VFAT though. Essentially the "freeze"
part involves telling the filesystem to sync all data, flush the
journal, and mark the filesystem clean. The intent under dm/LVM was
to allow you to make snapshots without having to fsck the just-
created snapshot before you mounted it.
> What happens if you try to boot and filesystems are frozen from
> previous run?
If you're just doing a fresh boot then the filesystem is already
clean due to the dm freeze and so it mounts up normally. All you
need to do then is have a little startup script which purges the
saved image before you fsck or remount things read-write since either
case means the image is no longer safe to resume.
If the kernel is later modified to purge all filesystem data (dcache/
pagecache) during snapshot and effectively remount and reopen all the
files by path during restore then you could remove that requirement.
You'd just need to make sure that the restore-from-disk scripts did
an fsck or journal-restore before reloading the old kernel data.
Cheers,
Kyle Moffett
Kyle Moffett wrote:
> On May 03, 2007, at 11:10:47, Pavel Machek wrote:
>> How mature is freezing filesystems -- will it work on at least ext2/3
>> and vfat?
>
> I'm pretty sure it works on ext2/3 and xfs and possibly others, I don't
> know either way about VFAT though. Essentially the "freeze" part
> involves telling the filesystem to sync all data, flush the journal, and
> mark the filesystem clean. The intent under dm/LVM was to allow you to
> make snapshots without having to fsck the just-created snapshot before
> you mounted it.
>
>> What happens if you try to boot and filesystems are frozen from
>> previous run?
>
> If you're just doing a fresh boot then the filesystem is already clean
> due to the dm freeze and so it mounts up normally. All you need to do
> then is have a little startup script which purges the saved image before
> you fsck or remount things read-write since either case means the image
> is no longer safe to resume.
Wouldn't it be better if freeze wrote a freeze-ID to the fs and returned it?
This would naturally be kept in the image and a UUID mismatch would be
detectable - seems safer and more flexible than 'a script'.
"This isn't the freeze you're looking for, move along"
David
On May 04, 2007, at 03:52:03, David Greaves wrote:
> Kyle Moffett wrote:
>> On May 03, 2007, at 11:10:47, Pavel Machek wrote:
>>> What happens if you try to boot and filesystems are frozen from
>>> previous run?
>>
>> If you're just doing a fresh boot then the filesystem is already
>> clean due to the dm freeze and so it mounts up normally. All you
>> need to do then is have a little startup script which purges the
>> saved image before you fsck or remount things read-write since
>> either case means the image is no longer safe to resume.
>
> Wouldn't it be better if freeze wrote a freeze-ID to the fs and
> returned it? This would naturally be kept in the image and a UUID
> mismatch would be detectable - seems safer and more flexible than
> 'a script'.
>
> "This isn't the freeze you're looking for, move along"
Possibly, but I was referring to the _current_ behavior of the device-
mapper freezing. While perhaps not ideal, it's currently very easily
usable.
Cheers,
Kyle Moffett