1:42 p.m.
Hello folks, long time no post... (Mailman has changed...)
So, big question re ssm and LUKS on LVM - I'm looking to increase /var
by 3G and create another LUKS volume for /usr/local of 3G.
I've reduced the size of two file-systems by 3G each: /home and /
And, then the LVMs on top.
The LVM on top of volume /var seems to have been expanded from 3G to 6G
and the LVMs on top of /home and / seem to have been reduced by 3G, but
the volumes /home and / are still showing a 3G difference between their
volume and file-system sizes...
I'm now attempting to increase the size of /var by 3G from 3G to 6G, but
no joy - no doubt I've got my logic on the what, were and how mixed up...
Terminal output of my commands to date are below - any help on where to
next would be very much appreciated :)
Thanks
Morgan
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 20.00 GB 20.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 195.73 GB 195.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 0.00 KB 237.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 0.00 KB 237.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size
FS FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 20.00
GB linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00
GB linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 195.73
GB linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB
ext4 3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB
ext4 3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00
GB crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 195.73 GB
ext4 195.73 GB 21.42 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 20.00 GB
ext4 20.00 GB 14.82 GB crypt /
/dev/sda1 260.00 MB
vfat part /boot/efi
/dev/sda2 500.00 MB
ext4 500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 20.00 GB 20.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 195.73 GB 195.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 0.00 KB 237.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 0.00 KB 237.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size
FS FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 20.00
GB linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00
GB linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 195.73
GB linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB
ext4 3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB
ext4 3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00
GB crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB
ext4 195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB
ext4 20.00 GB 14.70 GB crypt /
/dev/sda1 260.00 MB
vfat part /boot/efi
/dev/sda2 500.00 MB
ext4 500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[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.
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/root
WARNING: Reducing active and open logical volume to 17.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce fedora_morgansmachine/root? [y/n]: y
Size of logical volume fedora_morgansmachine/root changed from 20.00
GiB (5120 extents) to 17.00 GiB (4352 extents).
Logical volume root successfully resized.
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 17.00 GB 17.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 192.73 GB 192.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 6.00 GB 231.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 6.00 GB 231.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size
FS FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB
ext4 3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB
ext4 3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00
GB crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB
ext4 195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB
ext4 20.00 GB 14.70 GB crypt /
/dev/fedora_morgansmachine/root fedora_morgansmachine 17.00
GB linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00
GB linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 192.73
GB linear
/dev/sda1 260.00 MB
vfat part /boot/efi
/dev/sda2 500.00 MB
ext4 500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize -s+3G /dev/fedora_morgansmachine/var
Size of logical volume fedora_morgansmachine/var changed from 3.00
GiB (768 extents) to 6.00 GiB (1536 extents).
Logical volume var successfully resized.
[root@morgansmachine ~]# ssm resize -s+3G
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
SSM Error (2005): There is not enough space in the pool 'none' to grow
volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
6289408.0 KB!
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 17.00 GB 17.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 6.00 GB 6.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 192.73 GB 192.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 3.00 GB 234.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 3.00 GB 234.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size
FS FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 17.00
GB linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00
GB linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 6.00
GB linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00
GB linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 192.73
GB linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB
ext4 3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB
ext4 3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00
GB crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB
ext4 195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB
ext4 20.00 GB 14.70 GB crypt /
/dev/sda1 260.00 MB
vfat part /boot/efi
/dev/sda2 500.00 MB
ext4 500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
Traceback (most recent call last):
File "/usr/bin/ssm", line 48, in <module>
sys.exit(main.main())
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 1875, in
main
args.func(args)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 1060, in
resize
ret = args.volume['fs_info'].resize()
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 177, in
resize
return self._get_fs_func("resize", *args, **kwargs)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 167, in
_get_fs_func
return func(*args, **kwargs)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 230, in
extN_resize
new_size < self.data['fs_size']):
TypeError: unorderable types: NoneType() < int()
[root@morgansmachine ~]#
--
Morgan Read
United Kingdom
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
5:13 p.m.
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
[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
[root@localhost ~]# resize2fs -fp
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316 50522624
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316 to 50522624 (4k)
blocks.
resize2fs: Can't read a block bitmap while trying to resize
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
Please run 'e2fsck -fy
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316' to fix the
filesystem
after the aborted resize operation.
[root@localhost ~]# e2fsck -fy
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
e2fsck 1.42.13 (17-May-2015)
The filesystem size (according to the superblock) is 5242368 blocks
The physical size of the device is 4455936 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort? yes
[root@localhost ~]# resize2fs -fp
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6 4455936
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6 to 4455936 (4k)
blocks.
resize2fs: Can't read a block bitmap while trying to resize
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
Please run 'e2fsck -fy
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6' to fix the
filesystem
after the aborted resize operation.
[root@localhost ~]#
On 10 July 2016 at 14:42, Morgan Read <mstuff(a)read.org.nz> wrote:
Hello folks, long time no post... (Mailman has changed...)
So, big question re ssm and LUKS on LVM - I'm looking to increase /var by 3G
and create another LUKS volume for /usr/local of 3G.
I've reduced the size of two file-systems by 3G each: /home and /
And, then the LVMs on top.
The LVM on top of volume /var seems to have been expanded from 3G to 6G and
the LVMs on top of /home and / seem to have been reduced by 3G, but the
volumes /home and / are still showing a 3G difference between their volume
and file-system sizes...
I'm now attempting to increase the size of /var by 3G from 3G to 6G, but no
joy - no doubt I've got my logic on the what, were and how mixed up...
Terminal output of my commands to date are below - any help on where to next
would be very much appreciated :)
Thanks
Morgan
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 20.00 GB 20.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 195.73 GB 195.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 0.00 KB 237.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 0.00 KB 237.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 20.00 GB
linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00 GB
linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 195.73 GB
linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB ext4
3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB ext4
3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00 GB
crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 195.73 GB ext4
195.73 GB 21.42 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 20.00 GB ext4
20.00 GB 14.82 GB crypt /
/dev/sda1 260.00 MB vfat
part /boot/efi
/dev/sda2 500.00 MB ext4
500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 20.00 GB 20.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 195.73 GB 195.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 0.00 KB 237.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 0.00 KB 237.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 20.00 GB
linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00 GB
linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 195.73 GB
linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB ext4
3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB ext4
3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00 GB
crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB ext4
195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB ext4
20.00 GB 14.70 GB crypt /
/dev/sda1 260.00 MB vfat
part /boot/efi
/dev/sda2 500.00 MB ext4
500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[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.
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/root
WARNING: Reducing active and open logical volume to 17.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce fedora_morgansmachine/root? [y/n]: y
Size of logical volume fedora_morgansmachine/root changed from 20.00 GiB
(5120 extents) to 17.00 GiB (4352 extents).
Logical volume root successfully resized.
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 17.00 GB 17.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 192.73 GB 192.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 6.00 GB 231.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 6.00 GB 231.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB ext4
3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB ext4
3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00 GB
crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB ext4
195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB ext4
20.00 GB 14.70 GB crypt /
/dev/fedora_morgansmachine/root fedora_morgansmachine 17.00 GB
linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00 GB
linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 192.73 GB
linear
/dev/sda1 260.00 MB vfat
part /boot/efi
/dev/sda2 500.00 MB ext4
500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize -s+3G /dev/fedora_morgansmachine/var
Size of logical volume fedora_morgansmachine/var changed from 3.00 GiB
(768 extents) to 6.00 GiB (1536 extents).
Logical volume var successfully resized.
[root@morgansmachine ~]# ssm resize -s+3G
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
SSM Error (2005): There is not enough space in the pool 'none' to grow
volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
6289408.0 KB!
[root@morgansmachine ~]# ssm list
----------------------------------------------------------------------------
Device Free Used Total Pool Mount point
----------------------------------------------------------------------------
/dev/dm-0 0.00 KB 17.00 GB 17.00 GB crypt_pool
/dev/dm-1 0.00 KB 16.00 GB 16.00 GB crypt_pool
/dev/dm-4 0.00 KB 6.00 GB 6.00 GB crypt_pool
/dev/dm-5 0.00 KB 3.00 GB 3.00 GB crypt_pool
/dev/dm-6 0.00 KB 192.73 GB 192.73 GB crypt_pool
/dev/sda 238.47 GB PARTITIONED
/dev/sda1 260.00 MB /boot/efi
/dev/sda2 500.00 MB /boot
/dev/sda3 3.00 GB 234.73 GB 237.73 GB fedora_morgansmachine
----------------------------------------------------------------------------
-------------------------------------------------------------------
Pool Type Devices Free Used Total
-------------------------------------------------------------------
fedora_morgansmachine lvm 1 3.00 GB 234.73 GB 237.73 GB
-------------------------------------------------------------------
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
/dev/fedora_morgansmachine/root fedora_morgansmachine 17.00 GB
linear
/dev/fedora_morgansmachine/swap fedora_morgansmachine 16.00 GB
linear
/dev/fedora_morgansmachine/var fedora_morgansmachine 6.00 GB
linear
/dev/fedora_morgansmachine/opt fedora_morgansmachine 3.00 GB
linear
/dev/fedora_morgansmachine/home fedora_morgansmachine 192.73 GB
linear
/dev/mapper/luks-5c87de06-4ea4-4e6d-a3c3-86826791a892
crypt_pool 3.00 GB ext4
3.00 GB 2.30 GB crypt /opt
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
crypt_pool 3.00 GB ext4
3.00 GB 780.92 MB crypt /var
/dev/mapper/luks-6e1926c9-3b75-403b-917e-7f92388d71c6
crypt_pool 16.00 GB
crypt
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB ext4
195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB ext4
20.00 GB 14.70 GB crypt /
/dev/sda1 260.00 MB vfat
part /boot/efi
/dev/sda2 500.00 MB ext4
500.00 MB 354.80 MB part /boot
--------------------------------------------------------------------------------------------------------------------
[root@morgansmachine ~]# ssm resize
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
Traceback (most recent call last):
File "/usr/bin/ssm", line 48, in <module>
sys.exit(main.main())
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 1875, in main
args.func(args)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 1060, in
resize
ret = args.volume['fs_info'].resize()
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 177, in
resize
return self._get_fs_func("resize", *args, **kwargs)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 167, in
_get_fs_func
return func(*args, **kwargs)
File "/usr/lib/python3.5/site-packages/ssmlib/main.py", line 230, in
extN_resize
new_size < self.data['fs_size']):
TypeError: unorderable types: NoneType() < int()
[root@morgansmachine ~]#
--
Morgan Read
United Kingdom
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
--
Morgan Read
P 07563-650.923
E mstuff(a)read.org.nz
3:46 p.m.
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
6:42 a.m.
On 11/07/16 21:46, Chris Murphy wrote:
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.
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-superb...
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/
3:35 p.m.
On Sun, Jul 10, 2016 at 12:42 PM, Morgan Read <mstuff(a)read.org.nz> wrote:
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
[root@morgansmachine ~]# ssm resize -s-3G
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
These two commands should have at the least reduced the size of the
file system volumes mounted at /home and / but I have no idea why this
was permitted because online shrink is not supported by ext4.
---------------
# resize2fs /dev/VG/test4 40G
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/VG/test4 is mounted on /mnt/0; on-line resizing required
resize2fs: On-line shrinking not supported
# ssm resize -s-3G /dev/VG/test4
Do you want to unmount "/mnt/0"? [Y|n] n
fsadm: Cannot proceed with mounted filesystem "/mnt/0"
fsadm failed: 1
Filesystem resize failed.
SSM Error (2012): ERROR running command: "lvm lvresize -r -L
49283072.0k /dev/VG/test4"
---------------
If I allow the unmount:
---------------
[root@f24s ~]# ssm resize -s-3G /dev/VG/test4
Do you want to unmount "/mnt/0"? [Y|n] y
fsck from util-linux 2.28
/dev/mapper/VG-test4: 11/3276800 files (0.0% non-contiguous),
251699/13107200 blocks
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/mapper/VG-test4 to 12320768 (4k) blocks.
The filesystem on /dev/mapper/VG-test4 is now 12320768 (4k) blocks long.
Size of logical volume VG/test4 changed from 50.00 GiB (12800
extents) to 47.00 GiB (12032 extents).
Logical volume test4 successfully resized.
---------------
So why don't you have any messages about what actually ssm resize did?
I can't tell if it did anything at all, which means it probably did
not resize the file system. This appears to be true when looking at
ssm list results after you did this resize. The file systems are still
mounted at /home and /, and they are still the same size as before, no
change.
[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.
[root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/root
WARNING: Reducing active and open logical volume to 17.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce fedora_morgansmachine/root? [y/n]: y
Size of logical volume fedora_morgansmachine/root changed from 20.00 GiB
(5120 extents) to 17.00 GiB (4352 extents).
Logical volume root successfully resized.
Yeah I think you did just indeed destroy you data on both of these
because the file system was not resized in the first step and then you
asked it to change the size of the LV. So those extents revert back to
the VG.
Had the file system resize happened correctly, ssm will resize the LV
for you, so you didn't need to do this step anyway.
[root@morgansmachine ~]# ssm resize -s+3G
/dev/fedora_morgansmachine/var
Size of logical volume fedora_morgansmachine/var changed from 3.00 GiB
(768 extents) to 6.00 GiB (1536 extents).
Logical volume var successfully resized.
[root@morgansmachine ~]# ssm resize -s+3G
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
SSM Error (2005): There is not enough space in the pool 'none' to grow
volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
6289408.0 KB!
I think the problem here is now ssm is confused somehow. You should
have just done the 2nd command on the file system itself, because ssm
will know that it first must increase the size of the LV, and then the
size of the LUKS volume, and then the fs. But you only increased the
size of the LV, not the LUKS volume, which now has a different size
than its underlying LV, so SSM seems to get stuck.
Further, the problem is that by shrinking some LVs, and then growing
another, the extents for /home and / are now with some other LV and
have probably been stepped on, so /home and / are likely a total loss.
It would take some very tedious patience to unwind all of this in the
*exact* reverse order in order to get the same extents linearly
allocated back to the /home and / file systems.
[root@morgansmachine ~]# ssm resize
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
Traceback (most recent call last):
That's a bug. Anytime there's a crash it's a bug.
--
Chris Murphy
6:35 a.m.
On 11/07/16 21:35, Chris Murphy wrote:
On Sun, Jul 10, 2016 at 12:42 PM, Morgan Read
<mstuff(a)read.org.nz> wrote:
> [root@morgansmachine ~]# ssm resize -s-3G
> /dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
> [root@morgansmachine ~]# ssm resize -s-3G
> /dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
These two commands should have at the least reduced the size of the
file system volumes mounted at /home and / but I have no idea why this
was permitted because online shrink is not supported by ext4.
Well, it seems to have reduced the volumes, but not the filesystems:
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
...
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB
ext4 195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB
ext4 20.00 GB 14.70 GB crypt /
I've cut and pasted direct from the terminal - no omissions or additions
to the series of commands and outputs.
Following the two above commands, ssm lists the two volumes as reduced
in size by 3G, but the file system's size (FS size) as remaining the same...
I figured that was strange in itself - but stranger still as I seemed to
be able to increase the LV size of [...]/var by 3G, but then trying to
increase the underlying volume by the same amount failed politely with:
SSM Error (2005): There is not enough space in the pool 'none' to grow
volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
6289408.0 KB!
And then simply attempting to increase the size of the underlying volume
to fill the space caused ssm to fail very rudely and spit the dummy!
---------------
# resize2fs /dev/VG/test4 40G
resize2fs 1.42.13 (17-May-2015)
Filesystem at /dev/VG/test4 is mounted on /mnt/0; on-line resizing required
resize2fs: On-line shrinking not supported
# ssm resize -s-3G /dev/VG/test4
Do you want to unmount "/mnt/0"? [Y|n] n
fsadm: Cannot proceed with mounted filesystem "/mnt/0"
fsadm failed: 1
Filesystem resize failed.
SSM Error (2012): ERROR running command: "lvm lvresize -r -L
49283072.0k /dev/VG/test4"
---------------
If I allow the unmount:
---------------
[root@f24s ~]# ssm resize -s-3G /dev/VG/test4
Do you want to unmount "/mnt/0"? [Y|n] y
fsck from util-linux 2.28
/dev/mapper/VG-test4: 11/3276800 files (0.0% non-contiguous),
251699/13107200 blocks
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/mapper/VG-test4 to 12320768 (4k) blocks.
The filesystem on /dev/mapper/VG-test4 is now 12320768 (4k) blocks long.
Size of logical volume VG/test4 changed from 50.00 GiB (12800
extents) to 47.00 GiB (12032 extents).
Logical volume test4 successfully resized.
---------------
So why don't you have any messages about what actually ssm resize did?
Hmm, don't know - I generally understand that no message is a good
message: 'all done' ?
I can't tell if it did anything at all, which means it probably
did
not resize the file system. This appears to be true when looking at
ssm list results after you did this resize. The file systems are still
mounted at /home and /, and they are still the same size as before, no
change.
Hmm, yes - but volume size has changed - re my following email, it seems
to be a discrepancy between the superblock or partition table, which I
was trying to correct - is there a way to edit the superblock to conform
to the partition table?
This scenario looks similar to what's described here:
https://www.linuxquestions.org/questions/linux-hardware-18/size-in-superb...
> [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.
> [root@morgansmachine ~]# ssm resize -s-3G /dev/fedora_morgansmachine/root
> WARNING: Reducing active and open logical volume to 17.00 GiB.
> THIS MAY DESTROY YOUR DATA (filesystem etc.)
> Do you really want to reduce fedora_morgansmachine/root? [y/n]: y
> Size of logical volume fedora_morgansmachine/root changed from 20.00 GiB
> (5120 extents) to 17.00 GiB (4352 extents).
> Logical volume root successfully resized.
Yeah I think you did just indeed destroy you data on both of these
because the file system was not resized in the first step and then you
asked it to change the size of the LV. So those extents revert back to
the VG.
Had the file system resize happened correctly, ssm will resize the LV
for you, so you didn't need to do this step anyway.
Docs, docs, docs!
> [root@morgansmachine ~]# ssm resize -s+3G
/dev/fedora_morgansmachine/var
> Size of logical volume fedora_morgansmachine/var changed from 3.00 GiB
> (768 extents) to 6.00 GiB (1536 extents).
> Logical volume var successfully resized.
> [root@morgansmachine ~]# ssm resize -s+3G
> /dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
> SSM Error (2005): There is not enough space in the pool 'none' to grow
> volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
> 6289408.0 KB!
I think the problem here is now ssm is confused somehow. You should
have just done the 2nd command on the file system itself, because ssm
will know that it first must increase the size of the LV, and then the
size of the LUKS volume, and then the fs. But you only increased the
size of the LV, not the LUKS volume, which now has a different size
than its underlying LV, so SSM seems to get stuck.
Isn't
> [root@morgansmachine ~]# ssm resize -s+3G
/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
An attempt to increase the size of the LUKS volume?
Further, the problem is that by shrinking some LVs, and then growing
another, the extents for /home and / are now with some other LV and
have probably been stepped on, so /home and / are likely a total loss.
It would take some very tedious patience to unwind all of this in the
*exact* reverse order in order to get the same extents linearly
allocated back to the /home and / file systems.
Well, the steps I've followed aren't so complicated they couldn't be
retraced...
> [root@morgansmachine ~]# ssm resize
> /dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
> Traceback (most recent call last):
That's a bug. Anytime there's a crash it's a bug.
In performing this operation I took some comfort using ssm - in the
absence of any documentation I could find, other than this was the tool
for the job - from the changelog Mon Jul 27 2015:
- Error out if file system is not supported (#1196428)
I figured that if an operation wasn't supported, then ssm would say so...
As to resizing a live system - I figured there was some risk there, but
due to the lack of documentation and the 'error out if filesystem is not
supported' figured again that I'd would be allowed to complete if it
couldn't complete... I was most concerned that the operation wouldn't
be supported on a crypt system as there was documentation about 3 years
back that ssm only supported reading crypt filesystems - never thought
ext 4 would be the weak point...
Re resizing the LV before the underlying system - I had no idea that ssm
would take account of the LV when operating on the underlying system.
Again, documentation seems underwhelming. What I'm trying to do seems
to be precisely what ssm was made to simplify and do. But, in any case,
doing what needed to be done to the LV before the underlying system
seemed the safest option
The best documentation I could find was:
https://fedoraproject.org/wiki/Features/SystemStorageManager
http://storagemanager.sourceforge.net/
Both of which are at least 3 years old
And
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/...
Which is minimal
Yes, I have filed a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1354681
Many thanks for your follow - I'd be interested in your comments?
Regards
Morgan.
--
Morgan Read
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
10:24 a.m.
On Tue, Jul 12, 2016 at 5:35 AM, Morgan Read <mstuff(a)read.org.nz> wrote:
Well, it seems to have reduced the volumes, but not the filesystems:
--------------------------------------------------------------------------------------------------------------------
Volume Pool Volume size FS
FS size Free Type Mount point
--------------------------------------------------------------------------------------------------------------------
...
/dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
crypt_pool 192.73 GB ext4
195.73 GB 21.40 GB crypt /home
/dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
crypt_pool 17.00 GB ext4
20.00 GB 14.70 GB crypt /
You're right, this is damn peculiar.
The way I'm reading this, each LV is separately encrypted, is that
right? And then it's the dmcrypt/LUKS volume that is formatted ext4?
So:
ext4
|
LUKS
|
LV
|
VG
|
PV
|
Disk
If so, as far as I can tell it's correct to point it at the LUKS
volume, the thing that is mounted.
I've cut and pasted direct from the terminal - no omissions or
additions to
the series of commands and outputs.
Following the two above commands, ssm lists the two volumes as reduced in
size by 3G, but the file system's size (FS size) as remaining the same...
But what I'm seeing is *ONLY* the LUKS volume was reduced. The LV is
the same size as before.
ssm is apparently confused about the stack relationships. It's
treating the command literally for only the dmcrypt volume, not the
file system and not the LV. Off hand I'd say that's a really big bug.
> So why don't you have any messages about what actually ssm
resize did?
Hmm, don't know - I generally understand that no message is a good message:
'all done' ?
Nooo. It *had* to ask and it had to fail if it was an active mounted /
or /home. There's no way to unmount it even if you give permission.
> I can't tell if it did anything at all, which means it probably did
> not resize the file system. This appears to be true when looking at
> ssm list results after you did this resize. The file systems are still
> mounted at /home and /, and they are still the same size as before, no
> change.
Hmm, yes - but volume size has changed - re my following email, it seems to
be a discrepancy between the superblock or partition table, which I was
trying to correct - is there a way to edit the superblock to conform to the
partition table?
Only for grow. For shrink it's too late, it has no way to access the
now missing space at the end of the fs volume, but you can ask on the
ext4 list what the chances are of resizing the file system once the
partition (LUKS in this case) is already shrunk, out of the usual
order.
The LUKS volume shrinking itself doesn't immediately cause a problem,
it's the subsequent shrink of the LV, which will return extents used
for the file system into the VG, and then after that there was a grow
for a different LV which would have moved those extents from the VG to
that LV, and then the fs resize would have stepped on all that data.
So the portion removed from /home and / is just obliterated more than
likely.
You'd have to ask on the ext4 list to be sure if this is not fixable.
But my expectation from reading the resize.c code for ext4 is that it
will not resize a file system after the fact, there's required
accounting that has to be done and if it can't be done the operation
fails. e2fsck might be able to estimate that there was no meaningful
data or metadata in the missing portion, and could fix this *IF* the
LUKS volume is returned to original size the FS thinks it's supposed
to be on. But I expect e2fsck to fail also so long as the partition
its on is smaller than the fs says it should be because it cannot fix
the metadata in the missing 3GiB portion and e2fsck can't do a shrink
while fixing.
So it's catch 22. It can't be shrunk now because the proper accounting
can't be done. It can't be fixed until the partition is resized to
match the volume size, and even then the fixing may fail for multiple
reasons.
Docs, docs, docs!
>> [root@morgansmachine ~]# ssm resize -s+3G /dev/fedora_morgansmachine/var
>> Size of logical volume fedora_morgansmachine/var changed from 3.00 GiB
>> (768 extents) to 6.00 GiB (1536 extents).
>> Logical volume var successfully resized.
>> [root@morgansmachine ~]# ssm resize -s+3G
>> /dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
>> SSM Error (2005): There is not enough space in the pool 'none' to grow
>> volume '/dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f' to size
>> 6289408.0 KB!
>
>
> I think the problem here is now ssm is confused somehow. You should
> have just done the 2nd command on the file system itself, because ssm
> will know that it first must increase the size of the LV, and then the
> size of the LUKS volume, and then the fs. But you only increased the
> size of the LV, not the LUKS volume, which now has a different size
> than its underlying LV, so SSM seems to get stuck.
Isn't
>> [root@morgansmachine ~]# ssm resize -s+3G
>> /dev/mapper/luks-68a97c0e-00b5-4ab8-8628-2fae2605b35f
An attempt to increase the size of the LUKS volume?
Now I don't know. I'd expect ssm, the whole point of it is that it
should understand the layering, would for a shrink operation know to
first resize the file system, then LUKS volume header, then LV. In
that order. And in exact reverse order for grow. But it only changed
LUKS apparently.
When I tried it on Fedora 24, without LUKS, it did what I expected.
But I'd have to retry with LUKS to see if it gets confused.
As to resizing a live system - I figured there was some risk there,
but due
to the lack of documentation and the 'error out if filesystem is not
supported' figured again that I'd would be allowed to complete if it
couldn't complete... I was most concerned that the operation wouldn't be
supported on a crypt system as there was documentation about 3 years back
that ssm only supported reading crypt filesystems - never thought ext 4
would be the weak point...
resize2fs was apparently never even asked, otherwise it would have
failed. There is user space code to check for mount, it will not
shrink a mounted file system. It had to fail. ssm must be missing some
logical checks to totally silently reduce LUKS, which is a rather
nonsensical option. How else do you resize the file system in such a
case but to point to the logical block device the file system is on,
which is exactly what you did? But it did not attempt an fs resize
first.
I think it's a bug.
Re resizing the LV before the underlying system - I had no idea that
ssm
would take account of the LV when operating on the underlying system. Again,
documentation seems underwhelming. What I'm trying to do seems to be
precisely what ssm was made to simplify and do. But, in any case, doing
what needed to be done to the LV before the underlying system seemed the
safest option
I don't know what you mean by the last sentence. The LV is the
underlying system, LUKS volumes is above that, and the fs is above
that. Shrink has to be done top to bottom, which is what it seems you
started out doing. But then before really confirming the fs was
resized, you shrank the LV and ignored the warnings, which at that
point just seemed like ass covering warnings rather than, you are
definitely going to lose data now, kind of warnings.
--
Chris Murphy
8:38 a.m.
On 12/07/16 16:24, Chris Murphy wrote:
On Tue, Jul 12, 2016 at 5:35 AM, Morgan Read
<mstuff(a)read.org.nz> wrote:
>
> Well, it seems to have reduced the volumes, but not the filesystems:
>
--------------------------------------------------------------------------------------------------------------------
> Volume Pool Volume size FS
> FS size Free Type Mount point
>
--------------------------------------------------------------------------------------------------------------------
> ...
> /dev/mapper/luks-a69b434b-c409-4612-a51e-4bb0162cb316
> crypt_pool 192.73 GB ext4
> 195.73 GB 21.40 GB crypt /home
> /dev/mapper/luks-d313ea5e-fe14-4967-b11c-ae0e03c348b6
> crypt_pool 17.00 GB ext4
> 20.00 GB 14.70 GB crypt /
You're right, this is damn peculiar.
The way I'm reading this, each LV is separately encrypted, is that
right? And then it's the dmcrypt/LUKS volume that is formatted ext4?
So:
ext4
|
LUKS
|
LV
|
VG
|
PV
|
Disk
If so, as far as I can tell it's correct to point it at the LUKS
volume, the thing that is mounted.
Yes, that's it - I prefer to look up at the underside of the disk though :')
Historically, I've always had / /home and /usr/local on separate
partitions, then LVM came along, then LUKS came along - then I started
to find I wanted to preserve /var and /opt during upgrades. Perhaps, if
I didn't suffer from historical inertia then I would have encrypted the
whole disk putting LUKS on top of the LVM (or, below from the way you're
looking at disks - anyway, so individual partitions weren't encrypted
but the whole disk, or should that be PV or LV...). I've never been
able to see where the balance of benefits lies between LVM/LUKS and
LUKS/LVM.
> I've cut and pasted direct from the terminal - no omissions
or additions to
> the series of commands and outputs.
>
> Following the two above commands, ssm lists the two volumes as reduced in
> size by 3G, but the file system's size (FS size) as remaining the same...
But what I'm seeing is *ONLY* the LUKS volume was reduced. The LV is
the same size as before.
ssm is apparently confused about the stack relationships. It's
treating the command literally for only the dmcrypt volume, not the
file system and not the LV. Off hand I'd say that's a really big bug.
Hmm, yes. The developer seems to have acknowledged that on the bug report.
...
So it's catch 22. It can't be shrunk now because the proper
accounting
can't be done. It can't be fixed until the partition is resized to
match the volume size, and even then the fixing may fail for multiple
reasons.
Bugger! (Thank god I wasn't so cavalier to do this without b/u first!)
>
> Docs, docs, docs!
>
...
I don't know what you mean by the last sentence. The LV is the
underlying system, LUKS volumes is above that, and the fs is above
that. Shrink has to be done top to bottom, which is what it seems you
I'm a Kiwi - perhaps I see things the other way up? :)
Many thanks for your help getting to the bottom of this.
Regards
Morgan.
--
Morgan Read
<mailto:mstuffATreadDOTorgDOTnz>
Confused about DRM?
Get all the info you need at:
http://drm.info/
12:09 p.m.
On Tue, Jul 12, 2016 at 5:35 AM, Morgan Read <mstuff(a)read.org.nz> wrote:
Yes, I have filed a bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=1354681
I've reproduced the problem where ssm resize of a LUKS volume. It only
resizes the LUKS volume, not the underlying LV, and not the fs on the
LUKS volume. So it breaks the filesystem. It even does resize shrink
for XFS which is not supported.
I've updated the bug with my findings.
--
Chris Murphy
2843
days inactive
2847
days old
8 comments
2 participants
participants (2)
-
Chris Murphy -
Morgan Read