The cost of a snapshot cannot possibly be zero bytes. When a block is changed in the source volume, and you have a snapshot, a copy of the original block prior to modification must be made - the original data must be available somehwere so that it's accessible from the snapshot.
That's what the snapshot size is (plus some metadata): original copies of blocks that have since been changed in the source.
Note that it might be an "accounting trick": an implementation could choose not to overwrite the original block on disk, but rather store the new data somewhere else and update the source block list (or whatever it is it uses to track). In this case the snapshot is "static" as per your definition. But it still causes the overall number of allocated blocks to grow whenever a source block is modified. This space usage should be (an is) accounted against the snapshot.
This is true both for RO and RW snapshots, except that it's a bit more complex in the RW case (you don't want to overwrite a block that was modified in the snapshot by an original block from the source if that is modified too, for example).
I did it! I did it! I fixed it properly (I think).
Here's the story:
After some time the server turned out to be faulty and had to be scrapped. I kept disks and got everything else new. Then I reinstalled CentOS again on the SSD and then I attached the HDDs. LVM worked nicely, the disks were recognized, the configuration kept. But the same problem came up again - after a reboot, the volume was inactive.
However this time I chanced to notice something else - the bootloader passes the following parameters to the kernel:
crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet
Hmm, wait a minute, those look FAMILIAR!
Quick google query, and there we are:
rd.lvm.lv=
only activate the logical volumes with the given name. rd.lvm.lv can be specified multiple times on the kernel command line.
Well now. THAT explains it!
So, the resolution was (gathered from several more google queries):
- Modify
/etc/defaults/grub to include the additional volume in the parameters: crashkernel=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rd.lvm.lv=vg_home/lv_home rhgb quiet
- Reconfigure grub with
grub2-mkconfig -o /boot/grub2/grub.cfg
- Reconfigure initramfs with
mkinitrd -f -v /boot/initramfs-3.10.0-327.18.2.el7.x86_64.img 3.10.0-327.18.2.el7.x86_64. Note: your values may vary. Use uname -r to get that kernel version. Or just read up on mkinitrd. (Frankly, I don't know why this step is needed, but apparently it is - I tried without it and it didn't work)
- And finally, reinstall grub:
grub2-install /dev/sda
- Reboot, naturally.
TA-DA! The volume is active on reboot. Add it to fstab and enjoy! :)
Best Answer
A snapshot contains the differences between the original and the "mirrored" device. For being able to use both of them, it is necessary to map these differences to the "original" device (in memory). This is the more time-consuming, the fuller the "difference device" becomes.