4

Suppose we have one LV group with 2 logical volumes: /dev/lvm/home and /dev/lvm/root. Suppose I've accidentally deleted some important data on /dev/lvm/home, then turned off the PC the moment I realized that, changed /dev/lvm/home to mount only in read-only mode from fstab, booted from /dev/lvm/root and started using it, writing stuff on it, etc. Is my deleted data safe? I don't know how much about how LVMs work, can you overwrite the deleted data on one logical volume by writing data on another one from the same LV group? fdisk -l doesn't show the geometry of logical volumes so I suppose there is no such thing as geometry of a logical volume?

2
  • fstrim was run by a systemd timer (lol), but apparently, it's smart enough to not fstrim read-only volumes. sudo /sbin/fstrim --dry-run --listed-in /etc/fstab:/proc/self/mountinfo --verbose shows only /: 0 B (dry run) trimmed on /dev/mapper/lvm-root, so my data is safe. Apr 13 at 10:56
  • 1
    Yes. Just be aware that fstrim is voluntarily skipping filesystems (when reading from fstab) and still works if you're giving it the mountpoint as command line argument. There is nothing (for ext4 and others) that prevents discard just because of a readonly mount option. It's something to look out for since it can be unexpected. Good luck with your data recovery. Apr 13 at 13:22

3 Answers 3

5

Short answer: yes, your deleted data is as safe as it can be under the circumstances.

When you configure normal logical volumes (as opposed to "thin" ones), particular stretch(es) of disk blocks are allocated for each logical volume, and those won't change without using LVM configuration commands again. Unless you start changing the sizes of the logical volumes, the blocks that held the deleted files on your home LV will stay allocated to that LV, and won't be touched by other filesystems.

You can view a list of stretches of blocks allocated to each LV with lvdisplay -m /dev/lvm/home, pvdisplay -m /dev/sdXX, or dmsetup table.

(With "thin" LVs, it would be a matter of whether or not the filesystem was mounted with the discard option. With that option set, the filesystem will tell underlying layers that the deleted blocks are now free, and for a thin LV, it would mean the blocks can be released back into the "thin pool", ready to be reallocated to any other thin LV that is part of the same pool. But the discard mount option is not the default and no longer recommended for general use.)

What you should watch for is scheduled runs of fstrim, particularly if your disk is a SSD. Many modern distributions tend to run fstrim about once a week for every mounted filesystem, either as a cron/anacron job, or by a systemd *.timer unit. If you want to try and recover deleted data, you should disable that, just to be safe.


Unless you are into retrocomputing or otherwise deal with HDDs smaller than about 8 GB, you should consider disk geometry as "lies we tell old software/firmware for the sake of compatibility". Any disks larger than that are using LBA (Logical Block Addressing), basically just a block number.

Only the firmware of the disk itself cares about the real disk geometry, which is likely to be more complex than the classic C/H/S triplet can represent: for example, it is now standard for outer cylinders to contain more sectors than the inner ones. Any C/H/S numbers reported by fdisk are essentially complete fiction, maintained in case a new disk is plugged into a very old system.

5

Logical volumes are all separate, writing to one won’t affect another. LVs do have “geometry”, and you can see it by running

sudo dmsetup table

This will show how each LV (represented by constituent DM devices) is mapped.

Since you’re using LVs, a useful tool in such circumstances is the availability of snapshots: you can snapshot your home LV, to preserve its current state, and work off of that to recover data.

4

With normal Logical Volumes, each LV is separate same way partitions are separate.

LVM allocates extents from its Physical Volumes to each LV. Outside of snapshots, the same extent can not be given twice. So /dev/lvm/root may be using extents 0-1023, and /dev/lvm/home may be using extents 1024-2047. There is no overlap, so you can write whatever you want to Root-LV without harming Home-LV.

However there are other special cases like Thinly-Provisioned Logical Volumes, where extents are allocated dynamically. In this scenario, LV-Home may have freed some extents which may then subsequently be used and overwritten by LV-Root.

This works through fstrim or discard mechanism. If you're on SSD storage, data is gone once you fstrim anyway. Unfortunately fstrim might work even for read-only mounted filesystems.

So in addition to making it read-only (lvchange -p r), also disable fstrim (timer, cron, and/or chmod -x the binary itself), discard mount option, and also disable issue_discards in lvm.conf if it's enabled.

Unfortunately it is quite difficult to guarantee readonlyness. Mounting read-only may not be enough.

You must log in to answer this question.

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