0

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.

1
  • After having fixed this situation (see below), I can confirm that oddity 2 was a consequence of oddity 1, that is shortage of reserved space. Aug 14, 2016 at 7:16

2 Answers 2

3

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.

3
  • Thanks for this answer. Would you please expand on the opening "the better option would be to actually resize so enough diskspace is free to be safe"? Aug 10, 2016 at 19:26
  • 1
    I've extended the answer with some rationale.
    – madeddie
    Aug 10, 2016 at 23:26
  • Thanks. Using tune2fs -l on another computer I could ascertain that the Reserved block count (5921408) is 5% of Block count (118428160). Since the block Block size is 4096 (4 KiB), the reserved space is 22.6 GiB. The information on the same partition from df -h is /dev/sda8 445G 55G 367G 14% /home. Apparently 445 (size) = 55 (used) + 367 (available) + 23 (reserved) within round-off error. It makes perfect sense. Aug 12, 2016 at 8:10
-1

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.

7
  • this seems to overcomplicate the issue a bit. your problem was reserved space, plain and simple
    – madeddie
    Aug 14, 2016 at 11:18
  • @madeddie I had changed the title of the post to highlight your point. I do agree that the second answer is elaborate but it does not aim to shift the attention away from the reserved blocks issue. I will improve the form as the chance arises. Every user can edit the text for inaccurate content in this meantime. Aug 14, 2016 at 12:21
  • yes, mostly the "not recognized" is false, since it's recognized fine, it's just not enough free space :) your answer is mostly about syntax of the language to use while discussing the issue
    – madeddie
    Aug 14, 2016 at 12:22
  • @madeddie Please feel free to improve the terminology, by all means. The answer aims to help recognize the issue. It is for users who bump in the problem trusting the information from dfwithout knowing how it relates the reports from gparted or tune2fs. After you recognise, you can then discuss IMHO. Aug 14, 2016 at 12:29
  • @madeddie I have re-edited the content of my answer. Would you please revise whether this may help novices to the topic find their way? Sep 2, 2016 at 12:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .