Reclaim reserved disk space KVM/VMWare/Dedicated

mikhomikho AdministratorHosting ProviderOG
in LES Talk

Written by @mikho, 29 Apr 2021
Article was migrated from WordPress to Vanilla in March 2022

image

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[23] 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.

Theodore Tso

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 SizeByteKilobyteMegabyteGigabyte
1966080 * 40968053063680786432076807,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 SizeByteKilobyteMegabyteGigabyte
39321600 * 4096161061273600157286400153600150

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.

https://clients.mrvm.net

Thanked by (1)shadowban
Tagged:

Comments

Sign In or Register to comment.

© LowEndSpirit 2024

ipv6 ready