Question about Disk Usage on Morpheus Appliance

On my 3 Morpheus clusters, I noticed the root file system getting pretty full. But in drilling down, I see that the consumer of space, is an NFS mount. Now, the NFS mount is to /var/opt/morpheus/morpheus-ui which hangs off the root file system. And even though the NFS mount is reported separately when you run “df -h”, I am concerned that I might get a root file system exhausted error due to this NFS mount hanging off of /var, which is in root file system.

Do I need to be concerned about this?

[root@psp6npnfvims03 morpheus]# df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 12G 0 12G 0% /dev
tmpfs 12G 0 12G 0% /dev/shm
tmpfs 12G 89M 12G 1% /run
tmpfs 12G 0 12G 0% /sys/fs/cgroup
/dev/mapper/centos-root 50G 34G 17G 67% /
/dev/sda1 1014M 150M 865M 15% /boot
/dev/mapper/centos-home 142G 33M 142G 1% /home
x.x.x.x:/nfv_nonprod_morpheus_01 200G 50G 151G 25% /var/opt/morpheus/morpheus-ui
tmpfs 2.4G 0 2.4G 0% /run/user/0

Hi Mark,
Although your NFS fileshare is mounted on a directory in your root filesystem, the disk usage of your NFS fileshare is not being counted in your root filesystem usage.
From the output you have posted, your NFS share is 200GB in size and is using 50GB of that 200GB. Your root filesystem is 50GB in size and 34GB is used.
If you run the command du -sm * command from within your root directory, this will tell you the size in mb of the files and directories within the root filesystem. You can use this approach to identify what is consuming the space.

Yeah, I guess the space usage had to do with packages downloaded by Morpheus, et al.

I wound up last week doing an exercise to free up space on the VMs, and I will discuss a little bit about that.

In our lab environment, we had LVM on the 3 Morpheus virtual machine cluster nodes. And XFS was the file system being used. As superior as XFS is supposed to be (to ext4 for example), XFS file systems are not designed to be shrunk down.

What we wound up doing there, was adding a second VMDK (disk) to the VM, and moving /var to it (this entailed a series of steps covered in a MOP we put together). It is very difficult to size down the first (initial) VMDK, because of the aforementioned XFS file system and also because you have to use risky-to-use VMWare utilities to shrink down the VMDK file. So, we left the VMDK alone at its rather large size.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 200G 0 disk
├─sda1 8:1 0 1G 0 part /boot
└─sda2 8:2 0 199G 0 part
├─centos-root 253:0 0 50G 0 lvm /
├─centos-swap 253:1 0 7.9G 0 lvm [SWAP]
├─centos-home 253:2 0 141.1G 0 lvm /home
sdb 8:16 0 100G 0 disk
└─sdb1 8:17 0 100G 0 part
└─centos-var 253:3 0 100G 0 lvm /var
sr0 11:0 1 1024M 0 rom

The VMs in Production, these were not using LVM, and were using ext4 file systems. I guess different images were used to deploy the Linux VMs. We got “lucky” on these, because a) the VMDK size was considerably larger than the partition and b) the root file system was the last partition (boot was first, swap was second). We did not move /var to a new VMDK disk (/dev/sdb) on these VMs. All we had to do on these, was use fdisk, drop the root partition, then re-create it with more size. Dropping a root partition seemed scary. But it worked just fine. Of course, backing up your VMs is always necessary before doing these kinds of things.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 300G 0 disk
├─sda1 8:1 0 1G 0 part /boot
├─sda2 8:2 0 512M 0 part [SWAP]
└─sda3 8:3 0 100G 0 part /
sr0 11:0 1 1024M 0 rom