Should have read more on the subject before attempting this, but now I am much more informed… screwing things up tends to do that. Only learned of the shortcomings of xfs after the fact.
The OS was apparently installed with the default partitions and type, so there is (was) the following:
/dev/mapper/cl-root 50G xfs
/dev/mapper/cl-home 50G xfs
The cl-root was at 100% so thought I'd steal the space from cl-home since it wasn't really being used.
Did the following:
lvresize --size 10GB /dev/mapper/cl-home
lvresize --size 89GB /dev/mapper/cl-root
Both were successful and the changes are reflected in lvdisplay for each volume; however df -h was still showing them as the same size.
Decided to reboot which is where the screw up became apparent because it went into emergency mode due to /home not mounting properly. As a work around I modified /etc/fstab so that it was nofail for the /dev/mapper/cl-home which allowed me to boot up normally, although it did remake the /home directory.
I look at df -h and it is not showing /dev/mapper/cl-home and the filesystem is still showing the same size for /dev/mapper/cl-root. lvdisplay shows the adjust drive sizes.
Try to mount /home and get: mount: /dev/mapper/cl-home: can't read superblock.
From what I understand the process of reducing or increasing the size of a file system is two part: 1) modifying the logical volume and then 2) modifying the file system. I am under the impression I have already done 1) and just need to do 2).
Try:
resize2fs /dev/mapper/cl-home 10G
resize2fs 1.42.9 (28-Dec-2013)
resize2fs: Bad magic number in super-block while trying to open /dev/mapper/cl-home
Couldn't find valid filesystem superblock.
Try:
xfs_repair /dev/mapper/cl-home
Phase 1 - find and verify superblock...
error reading superblock 1 -- seek to offset 13315866624 failed
couldn't verify primary superblock - attempted to perform I/O beyond EOF !!!
attempting to find secondary superblock...
...Sorry, could not find valid secondary superblock
Exiting now.
Ok, well I guess I'll try to expand the /root then and basically get the same errors.
So at this point I just want to put it back the way it was.
lvresize --size 50G /dev/mapper/cl-root
WARNING: Reducing active and open logical volume to 50.00 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce cl/root? [y/n]:
Not sure I want to do that on this filesystem.
It doesn't seem I can increase the /dev/mapper/cl-home without decrease cl-root first.
So from where I stand I am kind of stuck. Everything is running fine at this point though, so I guess I could just leave it.
Any suggestions on how to resolve this?
Anyway, was using these links as guides.
http://www.microhowto.info/howto/increase_the_size_of_an_lvm_logical_volume.html
http://www.microhowto.info/howto/increase_the_size_of_an_ext2_ext3_or_ext4_filesystem.html
http://www.microhowto.info/howto/reduce_the_size_of_an_ext2_ext3_or_ext4_filesystem.html
Someone with a similar issue which leads me to believe that I should just leave it alone.
Best Answer
XFS filesystems can only be grown, they cannot be shrunk.
If your setup is likely to need filesystems to be shrunk use EXT4 instead.
Also - when using
lvresize, ensure you also use the-r/--resizefsoption, else you WILL mess up your filesystems, perhaps irretrievably. While I personally haven't tested it on reducing an xfs filesystem, I would expect it to report an error and not resize anything (as the xfs resize tool would be aware it cannot shrink a filesystem).