4

I'm a bit confused about how LVM snapshots are stored and work. I understand that when you create a snapshot with LVM, it doesn't take up any space, but as you make changes to the files on your system, your LVM snapshot volume will grow in size. If they grow in size past the size of their partition, they will be "dropped" and disappear, which is why it is not a good backup solution (other than the fact that it's also on the same physical system).

Does LVM snapshot storage work like the diagram below?

enter image description here

I am trying to show a scenario where the root filesystem partition is mostly empty and has a small amount of data shown in purple. I create a snapshot partition called "Snapshot 1" that gradually fills up when I make changes to the original files, although I'm pretty sure LVM is block-based rather than file-based.

Question

Does this mean that if I had a 100 GB root partition that was only storing 20GB of data, I would never need to worry about my snapshot partition overflowing if I gave it a 21GB size? Or would the snapshot partition have to be as large or larger than the root partition because it also records the differences of the unused space (blocks of 0's)?

Improve this question
5
  • is this a Linux OS or something else?
    – Jeff Schaller ♦
    Sep 13, 2017 at 13:45
  • Linux with LVM2
    – Programster
    Sep 13, 2017 at 13:50
  • The snapshot will only contain original copies of data before they have changed. The size of the snap shot therefore on the length of time you wish to keep it and depends on the number of changes being made.
    – Raman Sailopal
    Sep 13, 2017 at 14:04
  • @RamanSailopal but the key point from Emmanuel answer is that even the empty blocks are tracked right? So I can't be certain that a snapshot equal to the size of the blocks I've already actually filled with data, would be enough to prevent the snapshot partition running out of needed space.
    – Programster
    Sep 13, 2017 at 14:59
  • 1
    Yeah, there are no "hard and fast" rules unfortunately. You could have a volume group mapped to a file system with one file in it. If you make 200 changes to that file, the snap shot will soon grow bigger than the size of the file system. You will need to make a judgement of the changes to the file system involved once a snap shot has been created.
    – Raman Sailopal
    Sep 13, 2017 at 15:12

1 Answer 1

Reset to default
3

Unfortunately, the storage requirements are not quite that straight forward:

COW snapshots are created when a size is specified. The size is allocated from space in the VG, and is the amount of space that can be used for saving COW blocks as writes occur to the origin or snapshot. The size chosen should depend upon the amount of writes that are expected; often 20% of the origin LV is enough. If COW space runs low, it can be extended with extend (shrinking is also allowed with lvreduce.) A small amount of the COW snapshot LV size is used to track COW block locations, so the full size is not available for COW data blocks. Use lvs to check how much space is used, and see --monitor to to automatically extend the size to avoid running out of space. - man lvcreate

Note how the man page doesn't mention any particulars:

...often 20% of the origin LV is enough...A small amount of the COW snapshot LV size is used...

The conclusion I draw from this is that there's no specific way to calculate exactly what size the snapshot LV needs to be to ensure it never runs out of space.

Essentially, since the snapshot LV stores the original blocks prior to being changed, in order for it to never run out of space it would have to be large enough to hold the origin LV plus a little bit more so it can track the COW block locations.

Improve this answer
2
  • 1
    Thanks Emmanuel, I think I have a pretty good idea of how it works now. It works on a block basis, and the "empty" blocks are still tracked, so as you say, one would need a size equal to that of the original partition and then some more for the overhead. I guess that also means that if you looped through the blocks on the original partition to change them, each change would cause two writes. One copy operation of the block to the snapshot partition, before then applying the actual write to the root partition (as well as any writes for the overhead/tracking).
    – Programster
    Sep 13, 2017 at 14:55
  • 1
    --monitor to to automatically extend the size to avoid running out of space looks like what I might need if I want to avoid wasting space but ensure my snapshots partitions don't overrun.
    – Programster
    Sep 13, 2017 at 14:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .