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