Updating snapshot interfaces
The LVM2 snapshot CLI interface
REQUIREMENTS
The interface should be the same when using both non-shared and shared snapshots (so that the same scripts can run with both types of storage).
The interface should be similar when using snapshot-based storage and other types of storage (linear, striped, mirror) --- so that scripts that manipulate snapshot and non-snapshot storage can be written. Only the create command should be different, the resize and delete commands should be the same.
CREATING A SNAPSHOT
Currently implemented commands:
Create origin
(1) prompt> lvcreate -L 1G -n origin vg
Create snapshot (old method)
(2) prompt> lvcreate -s -L 1G -n snap vg/origin
Implemented by Milan recently:
Create snapshot with virtual invisible origin containing zeros
(3) prompt> lvcreate -s -L 1G --virtualsize 2G -n vsnap vg
- I just made the -s optional in-tree yesterday because we can deduce it from the other args - AGK 09/5/28
Implemented in Mikulas' experimental patches:
Create shared exception store (without any snapshot). It can use some fixed name, such as origin/vg-store (there is no need why the user would want to give a name to the whole shared store)
(4) prompt> lvcreate -s [--snapshotstore name] -L 1G vg/origin
(Mikulas: I'd oppose to using names like "type1", "type2", "type3" --- just like you don't have "type1", "type2", "type3" filesystems, they have names (ext2, ext3, xfs, reiserfs), you don't have "type1", "type2, "type3" disks, they have names (ide, sata, scsi, fiberchannel, sas) --- you shouldn't reference these exception store implementations with numbers. Names can be easily remembered than numbers).
New unimplemented commands:
Create snapshot in the shared exception store
(5) prompt> lvcreate -s -n snap vg/origin (for compatibility with old scripts, -L is ignored --- or can be processed by increasing the size of the shared store)
Both commands (4) and (5) can be batched into one
(6) prompt> lvcreate -s --snapshotstore name -L 1G -n snap vg/origin
Create shared exception store with virtual origin (the variant of command (4) with new exception store)
(7) prompt> lvcreate -s --snapshotstore name -L 1G --virtualsize 2G -n vsnap vg
The commands (2), (3), (5), (6) can take --virtualsize 123M parameter specifying the logical size of the space in the snapshot. For command (3) it is mandatory, for the rest of the commands it is optinal, if not specified the origin size is used.
(Create snapshot (new way - method 2)
prompt> lvcreate -L 1G -n snapshot_cow vg
prompt> lvcreate -s vg/origin [--snapshotstore type[123]] [-L <size>] -n snap vg/snapshot_cow --- Jon wrote this and I don't know what he meant, leaving it here, but not proposing it --- Mikulas)
The default snapshot store can be specified in lvm.conf file. If it is, then command (2) behaves just like command (6) and command (3) bahaves just like command (7).
DELETING A SNAPSHOT
Delete snapshot (unchanged)
prompt> lvremove vg/snap --- removes the snapshot
prompt> lvremove -r vg/snap --- removes the snapshot and if it was the last snapshot, also removes the exception store. Open question: which one of these two should be default? I'll still have to think about it.
ACTIVATION AND DEACTIVATION
With the shared shore there are relaxed rules for activation. If the snapshot is active, the origin must be also active. But if the origin is active, the indivial snapshots may be deactivated.
Open question: when to not activate snapshots automatically with activation of vg or origin? This is needed for rolling snapshots because there'll be too many of them. Use tags or some flag on the origin?
RESIZING SNAPSHOTS
Resize the non-origin or origin LV
prompt> lvresize -L 2G vg/origin
Resize the origin or non-origin LV, method 2
prompt --virtualsize 2G vg/origin
--- for non-snapshot volumes, -L and --virtualsize will do exactly the same thing. The reason is that commands for manipulating a snapshots should be the same as commands manipulating other types of volumes. So that virtualization team can write a single set of scripts and use these scripts to manipulate both snapshot and non-snapshot backed storage.
Change the physical size of the unshared snapshot (the allocated disk space)
prompt> lvresize -L 2G vg/snapshot
Change the physical size of the shared snapshot store
prompt> lvresize -L 2G vg/origin-store
Change the logical size of the shared or unshared snapshot, i.e. the size of the filesystem on the snapshot. It can be also applied to snapshots with virtual origin
prompt> lvresize --virtualsize 2G vg/snapshot
UNRESOLVED
- Do we disallow shrinking?
Mikulas: Virtual and physical shrinking isn't currently implemented, but can be done with moderate effort (the code to scan the whole store background is already there, it can just be extended to reallocate the chunks)
- Do we preserve the old size for the snapshots?
Mikulas: If the origin changes size, the virtual snapshot sizes should be preserved (so that snapshots are really immutable). They can be changed independently with lvresize --virtualsize.
MERGING SNAPSHOT BACK INTO ORIGIN
Merging (new method)
I like Mikulas' arguments...
http://people.redhat.com/mpatocka/patches/userspace/new-snapshots/preview/lvm-merge-man-lvconvert.patch<<BR>> or
prompt> lvconvert --merge vg/snap vg/origin
or the crappier option...
prompt> lvconvert --merge_src vg/snap --merge_dest vg/origin
Description
All other snapshots should also be preserved. If there are three snapshots, and one is merged back into the origin, the other two should remain valid.
UNRESOLVED
- What do we do if their address sizes differ?
CLONING AN EXISTING SNAPSHOT
There is no provision for this now.
Cloning (new way)
prompt> lvcreate -s --clone vg/snap -n <name> [-L <size>] [--snapshotstore type[123]]
... and as a side-thought, cloning a whole device using mirrors could be
prompt> lvcreate --clone vg/snap -n <name> [-L <size>]
UNRESOLVED
- Would we allow clones if different exstore types are used?
SNAPSHOTS OF SNAPSHOTS
There is no provision for this now.
Snapshots of snapshots (new way)
prompt> lvcreate -s vg/snap -L <size> [--snapshotstore type[123]]
Description
We should be able to take a snapshot of anything. The fact that we can't is a user-space tool limitation. I'm not sure I see the wisdom in adding clever in-kernel work-arounds to create snapshots of snapshots, when that only gets us part of the way to the whole solution. Will the work-around prove to be something useful, or something we discard later on?
The device-mapper snapshot constructor args and CLI interface
MAPPING TABLES
Origin
<start> <length> snapshot-origin <real-origin>
Snapshot
a) <start> <length> snapshot <real-origin> <exception store args>
or
b) <start> <length> snapshot <exception store args>
Exception store arguments
a) <type name> <#args> <exstore device> <chunk size> [additional args]
or
b) <type name> <#args> <real-origin> <exstore device> <chunk size> [additional args]
CREATING A SNAPSHOT
prompt> dmsetup create origin --table '<start> <length> snapshot-origin <real-origin>'
prompt> dmsetup create snap1 --table '<start> <length> snapshot <real-origin> \
type1 2 <exstore device> <chunk size>'