Reclaim reserved disk space KVM/VMWare/Dedicated
Written by @mikho, 29 Apr 2021
Article was migrated from WordPress to Vanilla in March 2022
Following up on the bonus tip posted on Resize your KVM VPS disk partition, 2 methods and bonus tip to reclaim disk space – Easy mode, here is a longer explanation and guide how to reclaim your reserved disk space.
Joe Dougherty from SecureDragon.net (great guy running a great company) sent me a tip about this thread and asked if I could write something about this “weird trick”. Actually it’s not a wierd trick, it’s a built in security feature. The information in this post will only work on dedicated servers or Virtual Servers that utilize full virtualization, meaning that this won’t work on OpenVZ.
On a newly created filesystems (Ext [2/3/4]) some of the space will be allocated for the system superuser (root) as “system reserved”. The default of 5% is meant for system partitions. If something goes wrong and your server consumes all its free disk space, the root user could still log in and check logs/crashdumps/etc and generally fix the situation.
For example, if your disk space fills up, the system logs (
/var/log) and root’s mailbox (
/var/mail/root) can still receive important information. For a
/home or general data storage partition, there’s no need to leave any space for root. For very special needs, you can even change the user that gets this emergency space.
There’s another reason to not allow an ext filesystem to get full, which is fragmentation. Ext4 should be better at this, as explained by Linux filesystem developer/guru Theodore Ts’o:
If you set the reserved block count to zero, it won't affect performance much except if you run for long periods of time (with lots of file creates and deletes) while the filesystem is almost full (i.e., say above 95%), at which point you'll be subject to fragmentation problems. Ext4's multi-block allocator is much more fragmentation resistant, because it tries much harder to find contiguous blocks, so even if you don't enable the other ext4 features, you'll see better results simply mounting an ext3 filesystem using ext4 before the filesystem gets completely full.If you are just using the filesystem for long-term archive, where files aren't changing very often (i.e., a huge mp3 or video store), it obviously won't matter.
If you have a VPS with small disk size the 5% won’t mean much but if you have a 100GB drive or bigger, it quickly adds up to a vaste amount of unused space. In those cases we could lower the amount of reserved space in order to claim and use a few more GB.
At the time of writing the original post, I actually had an unused XEN VPS so lets have a look at what we can do about this by using that as a real life example.
first we confirm the filesystem parameters by running this command:
# tune2fs -l /dev/xvda1
it will list all information about the disk. This is the output I got from my server:
tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 50fd54e4-7740-4683-b1e5-64e93d6d1e92 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery sparse_super large_file Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 9830400 Block count: 39321600 Reserved block count: 1966080 Free blocks: 38473681 Free inodes: 9799099 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 1014 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 RAID stride: 1 RAID stripe width: 80 Filesystem created: Mon Nov 10 19:05:08 2014 Last mount time: Sun Dec 14 17:25:37 2014 Last write time: Sun Dec 14 17:25:13 2014 Mount count: 12 Maximum mount count: 34 Last checked: Mon Nov 10 19:05:08 2014 Check interval: 15552000 (6 months) Next check after: Sat May 9 19:05:08 2015 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: e2ccf267-28ea-4e34-9df0-a349d06f0247 Journal backup: inode blocks
The ineresting part from the output above:
Reserved block count: 1966080 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root)
Before we move on to the amount of reserved space, take a moment to reflect on what user who is allowed to use the reserved space. By default it is root unless changed by the system administrator.
if you multiply the Reserved Block Count with the current Block Size (also found in the tune2fs output above)
Block size: 4096
we get how much space in bytes that is reserved by the system:
|Block count * Block Size||Byte||Kilobyte||Megabyte||Gigabyte|
|1966080 * 4096||8053063680||7864320||7680||7,5|
Doing the same operation using the Block Count value:
Block count: 39321600
will give you the Total Disk space of the drive
|Block count * Block Size||Byte||Kilobyte||Megabyte||Gigabyte|
|39321600 * 4096||161061273600||157286400||153600||150|
As you can see (7,5GB out of 150GB) exactly 5% of the disk is reserved space.
As previously mentioned, if you don’t have a large disk it would be wise to not change that 5% value since it could mean that you wont have enough “system reserved space” to recover from a full disk problem.
In my case, 7,5 GB of reserved space is a bit much and I would benefit if this was available for me to store my backups instead. So, how do we change the amount of reserved space?
Since my disk is in total 150GB each percentage is 1,5GB and I think that 1,5GB will be enough for this server, the command to set the reserved space to 1 percent would therefor look like this:
# tune2fs -m 1 /dev/xvda1
The returned result :
Setting reserved blocks percentage to 1% (393216 blocks)
Keeping in mind that each block is 4096 bytes the above result means the reserved space is:
393216 * 4096 = 1,5 GB
Before you jump of joy I would like to end this article with a few words of caution;
While this is a nice way to get some extra space on your server TAKE EXTREME CARE if you decide to change the settings on the drive that has the / volume or you could end up with a server that even root can’t save when the disk runs out of space. If you have a secondary drive that only holds data, may it be your mp3 collection or family photos, you can set the reserved space to 0percent on that drive. As long as it is NOT the system drive.