Reserved-blocks issue: partition size successfully changed but not recognized by the OS

Question

I run a dual-boot system, and the Linux distro is Ubuntu 14.04.

I have used GParted to enlarge a logical partition, named /dev/sda6, on which the /home directory is normally mounted. According to the GParted report the operation has been completed successfully. The partition is 85 GiB large, of which 83GiB used and 2 GiB free(d), as intended.

However this comes about with two oddities:

1. This gain is not recognized after logging in. As I check the disk usage with df -h, the report says that the partition /dev/sda6, duly mounted on /home, has a size of 85 GiB, of which 83 are used and 0 are available. The use is claimed to be 100%.

2. Another oddity is that I can regularly log into my user profile through the graphical user interface. After the credentials are recognized, though, the system stalls and it doesn't splash into the desktop environment. In order to get the df -h information, I need log in either with my regular identity in any text terminal or with the guest status in the graphic user interface. As a side remark, it doesn't look like data have been corrupted.

How can I fix this situation? The aim is to get the size increase of the partition fully available to the operating system. Thanks for helping me out.

Answer 1

You are probably using one of the ext filesystems (the default linux filesystem, usually ext4). Most of the time, when created, it will be created with a specific buffer called reserved blocks. This reserved space is meant to be only writable by system processes and root and therefor protect the OS from the disk filling by users.

The main purpose of df is to show the amount of disk space available out of a grand total. While it also shows the space used (by user), it doesn't do so with this reserved space.

This buffer is by default 5% of the whole disk. You can check if you have such a buffer with sudo tune2fs -l /dev/sda6 | grep Reserved. By typing sudo tune2fs -l /dev/sda6 | grep [bB]locks one can also read both the number of reserved blocks and the block size (in B), hence determine the space of the partition taken up by this construction. This would explain the system seeing 85GiB, but only 83 used and 0 free.

If you really want, you can set the buffer to a lower value with sudo tune2fs -m 2 /dev/sda6 (2 being an example value in percentage, which by default would be 5).

The better option would be to actually resize so enough disk space is free to be safe. 2GiB of 85GiB is only 2,35%, which isn't a lot and in most cases would fill up relatively fast. If you are sure your space usage will stay stable at 83GiB, then you can use tune2fs to reserve 0% of space for safety, but as soon as your disk fills up then (to 85GiB), you will not be able to log in at all and the machine will probably crash and be harder to repair.

The 5% safety margin is a relatively sane one. So, in this case, I'd make the partition at least 90GiB, but probably even 100 or more, just to have some space to spare for emergencies. Disk space is cheap, your time repairing the problems stemming from a filled-up disk is probably more expensive.

The answers to this question give some more insight into the reasoning.

Answer 2

In order to frame better the situation, some linguistic confusion should be cleared out. GParted, df and tune2fs use same or similar words for slightly different notions concerning disk space.

I rewrote my understanding in terms of pseudo-equations and overloaded these operators:

'=' means 'corresponds to'
'@' means 'according to'

I started off using df -h and leave this understated farther on. Note that tune2fs -l, subject to appropriate syntax, normally returns block counts as well as the block size. By multiplying the one by the other, one gets the disk space size. Make sure that disk space measures are expressed in the same base (either 2 or 10).

Firstly, taking the viewpoint of GParted

size @ gparted = size @ df = block count * block size @ tune2fs
unused @ gparted = free blocks * block size @ tune2fs 
used @ gparted = used @ df = (block count - free blocks) * block size @ tune2fs

It is pretty intuitive so far.

Then, taking the viewpoint of df

size @ df = size @ gparted = block count @ tune2fs 
used @ df = used @ gparted = (block count - free blocks) *block size @ tune2fs
available @ df = max[(free blocks - reserved block count) * block size @ tune2fs, 0]

Therefore, available@df means something different from free@tune2fs and unused@gparted.

In summary, the available space in df measures the excess of the total space, said to be free in tune2fs or unused in gparted, over the quota reserved by tune2fs. When this excess is zero, it indicates a shortage of the disk space kept aside for good functioning.