On Sat, Dec 28, 2019 at 4:12 AM Utpal Bora <cs14mtech11017@xxxxxxxxxx> wrote: > > Hi, > > My XFS home drive is corrupt after trying to extend it with lvm. > This is what I did to extend the partition. > 1. Extend Volume group to use a new physical volume of around 1.2TB. > This was successful without any error. > vgextend vg-1 /dev/sdc1 > > 2. Extend logical volume (home-lv) to use the free space. > lvextend -l 100%FREE /dev/mapper/vg--1-home--lv -r What approximate byte value is 100%FREE ? > 3. Resized home-lv and reduce 55 GB > lvreduce -L 55G /dev/mapper/vg--1-home--lv -r If this is really a volume reduction, along with -r I would expect this entire command to fail. XFS doesn't support shrink. Since a successful LV shrink requires shrinking the file system first, or else it results in truncation of the file system it contains and thus damages it, off hand I think this is a bug in lvreduce, or possibly in fsadm which is what -r calls to do the resize. My suggestion is to make no further changes at all, no further recovery attempts. And head over to the LVM list and make the same post as above. It's very possible there's backup LVM metadata that will reference the PE/LE's used in the LV prior to the lvreduce. By restoring the LV using that exact same mapping, it should be possible to recover the file system it contains. But only if you don't make other attempts. The more additional attempts the greater the chance of irreparable changes. https://www.redhat.com/mailman/listinfo/linux-lvm > I assumed that -r will invoke xfs_grow internally. Right, but xfs_grow only grows. It doesn't shrink. So my expectation is that the lvreduce command should fail without having made any changes. And yet... -- Chris Murphy
