0

This is the current state of my disk at present , how can I use the unused space or move stuff to free up space , without formatting or loosing data

Filesystem Size Used Avail Use% Mounted on devtmpfs 7.6G 0 7.6G 0% /dev tmpfs 7.7G 121M 7.5G 2% /dev/shm tmpfs 7.7G 2.0M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/Root 50G 50G 336M 100% / /dev/nvme0n1p2 3.0G 467M 2.6G 16% /boot /dev/nvme0n1p1 200M 17M 184M 9% /boot/efi /dev/mapper/Home 100G 30G 71G 30% /home tmpfs 1.6G 52K 1.6G 1% /run/user/119637 

Output of lvmdiskscan

 /dev/mapper/luks-e66c5c74-2af5-4500-9e5f-011c23ab17aa [ 235.26 GiB] LVM physical volume /dev/nvme0n1p1 [ 200.00 MiB] /dev/nvme0n1p2 [ 3.00 GiB] /dev/nvme0n1p3 [ <235.28 GiB] 0 disks 3 partitions 1 LVM physical volume whole disk 0 LVM physical volumes 

Can I merge home partition or add a partition for root from home as it has more space ? Are below steps logical ?

  1. Make another partition of home
  2. Merge that to root ( No idea on commands how to do)
  3. Say if I provide 10G from home to root it will resolve storage issue for my machine and all data will be intact .

As workaround for now , just moved the most heavy files

# find . -type f -size +1G ./VirtualBox VMs/origin-1.3.0/box-disk1.vmdk ./VirtualBox VMs/virtualBox-related_default_1654693896122_36201/centos-7-1-1.x86_64.vmdk ./.vagrant.d/boxes/thesteve0-VAGRANTSLASH-openshift-origin/1.2.0/virtualbox/box-disk1.vmdk # mv "./VirtualBox VMs/origin-1.3.0/box-disk1.vmdk" /home/ # df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 7.6G 0 7.6G 0% /dev tmpfs 7.7G 155M 7.5G 2% /dev/shm tmpfs 7.7G 2.0M 7.7G 1% /run tmpfs 7.7G 0 7.7G 0% /sys/fs/cgroup /dev/mapper/Root 50G 40G 11G 79% / /dev/nvme0n1p2 3.0G 467M 2.6G 16% /boot /dev/nvme0n1p1 200M 17M 184M 9% /boot/efi /dev/mapper/Home 100G 40G 61G 40% /home tmpfs 1.6G 48K 1.6G 1% /run/user/119637 

Not sure how this will impact using virtualbox :)

1
  • moving the vmdks off is a good idea. better is to move the entire parent directory and make it all a symlink to wherever you put it on /home that way any new vms you create will automatically Unfortunately, there are no real standards for placing all these files and lots of software will default to /var. but it shouldn't be hard to get any software pointed to the new location, with symlinks, they will not even have to know about the new location.
    – toppk
    CommentedSep 22, 2022 at 5:12

2 Answers 2

0

Your lvmdiskscan indicates you have a LVM physical volume (PV) on a LUKS-encrypted volume, probably at /dev/nvme0n1p3. It is about 235 GiB in size. If your /dev/mapper/Root and /dev/mapper/Home are actually LVM logical volumes, they would occupy only 150 GiB, and so you might have about 85 GiB of unallocated encrypted LVM disk space you could use to extend your root filesystem without shrinking anything. You could even be able to extend the filesystem on-line, while it's mounted and in use.

However, the device names /dev/mapper/Root and /dev/mapper/Home don't look like LVM device names: LVM logical volumes would normally use either /dev/<vg name>/<lv name> or /dev/mapper/<vg name>-<lv name> syntax. If they are encrypted partitions, on which physical disk are they located, and what is their relative positioning? That will have a significant effect on the procedures required.

Without knowing exactly what your /dev/mapper/Root and /dev/mapper/Home are, it won't be possible to give you accurate advice on how to best achieve your root filesystem extension. If they employ multiple device-mapper layers, then dmsetup ls --tree -o blkdevname might be useful in making sense of how the various mapping layers interact with each other.

Also, you have not disclosed the filesystem types used on /dev/mapper/Root and /dev/mapper/Home. The filesystem type has important implications: for example, if your /dev/mapper/Home is an XFS filesystem, it currently cannot be shrunk at all without backing up the data, re-mkfs'ing the filesystem in a smaller size & restoring, as (as far as I know) there is no production-quality XFS filesystem shrinking tool in existence as yet.

    0

    You should check vgs output to see do you have free space in VG. If there is enough free space in VG just grow /dev/mapper/Root and filesystem on it.

    If you don't have free space in VG shrink filesystem on /dev/mapper/Home and shrink /dev/mapper/Home LV than grow /dev/mapper/Root LV and filesystem on it.

    https://documentation.suse.com/sles/15-SP1/html/SLES-all/cha-resize-fs.html

    https://www.mankier.com/8/lvreduce

    https://www.mankier.com/8/lvresize

    https://www.mankier.com/8/lvm

      You must log in to answer this question.

      Start asking to get answers

      Find the answer to your question by asking.

      Ask question

      Explore related questions

      See similar questions with these tags.