JLS2009: A Btrfs update [LWN.net]

JLS2009: A Btrfs update

Posted Nov 8, 2009 3:18 UTC (Sun) by butlerm (subscriber, #13312)
In reply to: JLS2009: A Btrfs update by giraffedata
Parent article: JLS2009: A Btrfs update

I understand that ZFS and Netapp use a very similar copy on write technique
to make read only snapshots of filesystems (hence the lawsuit). NetApp uses
the same scheme to make read only snapshots of virtual block devices as well.

The problem is something like that is probably much too complex for LVM,
comparable in complexity to BTRFS itself. So for LVM to avoid the copy
before write problem, presumably it would have to use a scheme where the
physical locations of one or more versions of each block are stored in an
persistent segment somewhere.

However, if the version tracking segment is itself on a typical storage
device, every random write to something that a snapshot has been taken of
requires both a write to a new block on the disk and a write to the version
pointer entry. Short of locating the segment in NVRAM or a more reliable
than average flash device that is a bit of a problem.

(Log in to post comments)

JLS2009: A Btrfs update

Posted Nov 8, 2009 11:54 UTC (Sun) by nix (subscriber, #2304) [Link]

If there's md in there as well, with its superblock updates to track the
array dirty state, one write could be amplified to, what, six? (of course
you don't get a superblock update with every write unless writes are quite
rare... but often writes *are* rare.)