Is there a "reverse COW" filesystem or LVM feature for Linux?

Question

Is there any sort of filesystem or volume manager on Linux that supports COW snapshots, but instead of writing out new blocks for a new snapshot, it copies the old, unchanged blocks and does an in-place replacement for the new write? I don't know if there's a formal name for this system design technique but it's a sort of inverse COW.

Specifically, in the language of LVM, I'd like to have a system with multiple physical volumes combined into a single volume group. There would be one read/write logical volume that contains the latest copy of filesystem data blocks. You could add a new physical volume and assign it to store a read-only (from userspace's perspective) historical snapshot of the read/write logical volume. As you make writes to the read/write logical volume the old copy of data is copied to your read-only physical volume and the new copy is written in place to the read/write volume.

The purpose of this design is to let you cleanly drop an old snapshot, all of its data and its physical volume in one go with little to no extra copying. If you did this in the normal way with LVM snapshots or a COW filesystem your old disk has a copy of all the un-COWed old data, instead of just the COWed old data, and you have to copy all of the untouched data off of the disk before it can be removed.

Answer 1

LVM is based on extents: small regions of the disk that are assigned on the fly instead of large partition-like regions. A snapshot or logical volume is going to reference a bunch of these extents in its volume but this is fundamentally not different from how the original logical volume worked. At any time you can delete an old snapshot and it will simply free all the extents it's sole owner of (parts of the volume changed in the newer state) with no drama about having to copy things over.

Physically, on a very fresh disk, these extents are likely to be laid-out on a Physical Volume in the order you think, but that's only in that trivial case. It's much more likely that deleting the snapshot frees up a fragmented set of extents the same way deleting the live state of the volume does. So from a practical standpoint if you have LVM there's no difference between what you want and what you'll get by deleting a snapshot.

Answer 2

According to the lvm2 docs on snapshots, there are two dm target types that are used here:

snapshot-origin

[...] For each write, the original data will be saved in the <COW device> of each snapshot [...]

Which does the "copy original data to COW disk, overwrite on main disk" dance.

snapshot

[...] Writes will only go to the <COW device>. [...]

Self-explanatory. No copies done.

To create the snapshot, lvm2 sets it up like this:

1. a device containing the original mapping table of the source volume;
2. a device used as the <COW device>;
3. a "snapshot" device, combining #1 and #2, which is the visible snapshot volume;
4. the "original" volume (which uses the device number used by the original source volume), whose table is replaced by a "snapshot-origin" mapping from device #1.

So that means we have two visible mounts. One is #3, the snapshot we just took. The other is #4, which is the mount that we took a snapshot of.

Any writes to #3, the snapshot mount, go directly to the COW device as it is a snapshot target. This is assuming that the snapshot was mounted as r/w.

Any writes to #4, the original mount, have the original data copied to the COW device and the new data written in place. This is because it is a snapshot-origin target.

So to answer my question: if you took a read-only snapshot, and got lvm2 to create its COW device on the physical volume you plan on removing, you'd get the behavior I'm asking for. It also seems that lvcreate supports this scenario:

Create a COW snapshot LV of an origin LV

lvcreate --type snapshot --size Size LV PV

To control which PVs a new LV will use, specify one or more PVs as position args at the end of the command line. lvcreate will allocate physical extents only from the specified PVs.

Which seems to imply that the PV specified on the command line will house the COW device (#2 from above).