Re: ssm resize luks on lvm...
On Sun, Jul 10, 2016 at 4:13 PM, Morgan Read <mstuff(a)read.org.nz> wrote:
Hmm, after trying to reboot and falling into emergency recovery,
this
doesn't look good. And, after booting from live media and attempting
the following, this looks very bad indeed... I'm not sure
system-storage-manager should have allowed this... bugs, bugs,
bugs.... And more bugs, serious bugs
Why the first resizes resulted in exactly no messages at all? I can't
reproduce that with system-storage-manager-0.4-10.fc24.noarch. It asks
about the mounted volume, whether to umount it first.
But it does seem clear in your case the file system was not resized.
I would say this part is improper design and a valid bug to file:
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/home
WARNING: Reducing active and open logical volume to 192.73 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce fedora_morgansmachine/home? [y/n]: y
Size of logical volume fedora_morgansmachine/home changed from
195.73 GiB (50107 extents) to 192.73 GiB (49339 extents).
Logical volume home successfully resized.
By definition this is going to destroy data, not merely it may destroy
data. It should have all available information to know the file system
is size X, and that this operation will make the LV size X - 3G, which
*will* with 100% certainly obliterate the file system. And then it
permits it.
This type of resize operation should fail. It should not be possible
to do a resize through ssm (or any GUI resizer) and lose data in this
fashion. It should require that you delete the LV in order to destroy
it, not destroy it via resizing. Or require that wipefs be used on the
LV or LUKS volumes before the resize will work.
It needs to be more fail safe that this. But it did to exactly what
you asked it to do. And ssm lit very clearly showed that it had NOT
shrunk your file system volume before you decided to make the LV
smaller than the file system.
[root@localhost ~]# e2fsck -fy
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
e2fsck 1.42.13 (17-May-2015)
The filesystem size (according to the superblock) is 51309056 blocks
The physical size of the device is 50522624 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes
These file systems are toast. Hopefully you have a backup of /home at least.
--
Chris Murphy