On Tue, Mar 11, 2003 at 09:46:16PM +0100, jon+lvm@silicide.dk wrote: > > How would you not do that ? You have to store the snapshots some how. Right you do have to store them. But if the block references were in the reverse direction than they are currently then the disk penalty for snapshots would not increase linearly with the number of snapshots. As I understand it, the way LVM works currently is that if a block that is in one or more snapshots is going to be altered, the contents of the block, prior to commiting the new contents, is copied to all of the snapshots, one copy per snapshot, hence the linear penalty to keeping multiple snapshots. However if the updating of a block that was in one or more snapshots were done such that the existing block was not overwritten but instead a new block was allocated for the "live" (non-snapshot) device to write the new contents, there would be a constant cost (the cost of writing one block and accounting for it in the "live" device) rather than a linearly increasing cost no matter how many snapshots there were. This is not likely possible the way LVM works currently (or it would work this way :-) however. This is one of the advantages filesytem level snapshots have over block level snapshots. Filesystems can change block pointers easily enough that it can make one constant cost change per overwritten block no matter how many snapshots are referencing the old block still. b. -- Brian J. Murrell
Attachment:
pgp00484.pgp
Description: PGP signature
