Re: Back to the future.

From: Kyle Moffett
Date: Fri Apr 27 2007 - 21:26:37 EST


On Apr 27, 2007, at 21:15:28, Rafael J. Wysocki wrote:
On Saturday, 28 April 2007 03:03, Kyle Moffett wrote:
On Apr 27, 2007, at 18:07:46, Nigel Cunningham wrote:
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]

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.
2) Iterate over the userspace process list, freezing each process and remapping all of its pages copy-on-write. Any device-specific pages need to have state saved by that device.

Why do you want to do 2) after 1) and not vice versa?

(1) can be done without extra locking. Device-mapper already has code to freeze filesystems and that makes a natural process-stopping point. Any threads doing IO will very quickly put themselves to sleep at (1) and save us some effort during step 2.

6) Kernel unfreezes all userspace processes and returns the snapshot FD to userspace (where it can be read from).

Okay, but how do we do the error recovery if, for example, the image cannot be saved?

If the image can't be saved then there are 2 options:
(1) Call sys_restore() with the image
(2) Pass your snapshot file-descriptor to sys_unsnapshot()

In the former case, the system will be restored to the state it was at a few seconds earlier, right as it took the snapshot. In the latter case the modified-in-memory snapshot pages will be synced back to the disk filesystems, the copy-on-write data-structures torn down (think of merging an LVM snapshot back into its base device), and the memory allocated for the snapshot will be freed. Either way the system is properly in sync with disk again, the only difference is whether you want to preserve the userspace state from during the attempted snapshot (IE: any error status). You could also save the error state in case (1) by just auto-posting a bug-report on http:// bugs.$VENDOR.com/ of course :-D.

Cheers,
Kyle Moffett

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