• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Wrong calculation of disk usage

ronnyj

New Pleskian
Hello, I'm running Plesk 12.0.18 on Centos 7,
recently I've got emails from backup service stating that it could not complete
the backup due to insufficient space available on disk.
Normally I have plenty of disk space available so I check the disk using the command
df -h

Filesystem Size Used Avail Use% Mounted on
/dev/root 20G 2.3G 17G 13% /
/dev/md2 91G 82G 4.4G 95% /var

it seems that /var has been growing up a lot,
but if I run the command
du -sh /var
I get a total size of 5.7G (not 82G as stated before)

any idea?
is Plesk calculating the wrong size or it's me using the wrong commands?
 
Hello Ronny,

The most common cause of this effect is open files that have been deleted.

The kernel will only free the disk blocks of a deleted file if it is not in use at the time of its deletion. Otherwise that is deferred until the file is closed, or the system is rebooted.

A common Unix-world trick to ensure that no temporary files are left around is the following:
  • A process creates and opens a temporary file

  • While still holding the open file descriptor, the process unlinks (i.e. deletes) the file

  • The process reads and writes to the file normally using the file descriptor

  • The process closes the file descriptor when it's done, and the kernel frees the space

  • If the process (or the system) terminates unexpectedly, the temporary file is already deleted and no clean-up is necessary.

  • As a bonus, deleting the file reduces the chances of naming collisions when creating temporary files and it also provides an additional layer of obscurity over the running processes - for anyone but the root user, that is.
This behaviour ensures that processes don't have to deal with files that are suddenly pulled from under their feet, and also that processes don't have to consult each other in order to delete a file. It is unexpected behaviour for those coming from Windows systems, though, since there you are not normally allowed to delete a file that is in use.

The lsof command, when run as root, will show all open files and it will specifically indicate deleted files that are deleted:
Code:
# lsof 2>/dev/null | grep deleted
bootlogd 2024 root 1w REG 9,3 58 917506 /tmp/init.0W2ARi (deleted)
bootlogd 2024 root 2w REG 9,3 58 917506 /tmp/init.0W2ARi (deleted)
Stopping and restarting the guilty processes, or just rebooting the server should solve this issue.

Deleted files could also be held open by the kernel if, for example, it's a mounted filesystem image. In this case unmounting the filesystem or rebooting the server should do the trick.

In your case, judging by the size of the "missing" space I'd look for any references to the file that you used to set up the server e.g. the Centos DVD image that you deleted after installing.
 
Thanks Abdi for the amazing support!
The guilty process was mysql, a restart has solved the problem.
Have a good day,
Ronny.
 
Back
Top