On 11/07/16 21:46, Chris Murphy wrote:
On Sun, Jul 10, 2016 at 4:13 PM, Morgan Read <mstuff@xxxxxxxxxxx> 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.
As, ext4 doesn't require any defragging, I guessed that it would arrange
the data at the head of the file system and this operation would take
space from the rear - but, I have to say, I was aware of taking the risk...
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.
I entirely agree - as in my last email, I took some comfort from the
changelog that indicated that ssm would fail where it could not perform
on a particular filesystem
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.
Thanks Chris for that encouragement :) Yes, I do have back up of /home.
Re the link in my last email
https://www.linuxquestions.org/questions/linux-hardware-18/size-in-superblock-is-different-from-the-physical-size-of-the-partition-298175/#post3813076
I'll see if I can mount anything from live image and see if that helps.
Regards
Morgan.
--
Morgan Read
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://lists.fedoraproject.org/admin/lists/users@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
