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).


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.


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.




Someone with a similar issue which leads me to believe that I should just leave it alone.


  • You cannot shrink an XFS filesystem except by backup/format/restore.
    – fpmurphy
    Sep 21 '17 at 0:27

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 / --resizefs option, 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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.