Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a very very insane problem with my ssd sata harddisk.

I did fill the harddisk, and Thunderbird complained about "no space left on device".

But even if I delete some files from the harddisk, df will still say 0 blocks free. But it will decrease the number of used blocks. So it looks like it is freeing the blocks and deleting the files, but it don't put the blocks back to the free pool.

But here is where things get insane: If I log in with my normal user, I get a "No free space" when I try to write to the harddisk. But If i log in as root I can write to the file system, despite the fact that df is saying 0 blocks free.

I did try to run fsck -f but it just run its test and then say that anything is fine. But it run for less then 10 seconds, is this expected on a 40GB ssd partition?.

Does anyone have any clue about what might be wrong here?.

This is using Fedora 14 with ext4.

The output of: tune -l /dev/sda2 (My / and only partition) is:

tune2fs 1.41.12 (17-May-2010)
Filesystem volume name:   myroot
Last mounted on:          /
Filesystem UUID:          14079141-278f-437e-b042-7271a2ac07ed
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2150288
Block count:              8600576
Reserved block count:     430028
Free blocks:              380030
Free inodes:              1775702
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1021
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Sat Jul 31 21:49:31 2010
Last mount time:          Fri Nov 26 17:38:42 2010
Last write time:          Fri Nov 26 16:44:15 2010
Mount count:              3
Maximum mount count:      -1
Last checked:             Fri Nov 26 16:44:15 2010
Check interval:           0 (<none>)
Lifetime writes:          386 GB
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:      a0bb9b2c-9238-49eb-94c9-9979fb0fd825
Journal backup:           inode blocks
share|improve this question
up vote 1 down vote accepted

To list the contents of the file system superblock use this command:

tune2fs -l <device>

Please note that this takes the physical device, not the mount point, as its parameter.

Items of interest are your free inode count, free block count, and reserved block count. Assuming that you have this file system mounted somewhere important, here meaning a system-necessary directory tree such as /, it is advisable to maintain reserved super user blocks. If, however, you have limited option you can leverage the tune2fs command again as:

tune2fs -m n <device>

to set the percentage of the file system reserved for the super user to n.

share|improve this answer
I will try that, but I don't think that is the problem. Because why should the root user be able to write to the disk, but the normal user get a "disk full" error? – MTilsted Nov 26 '10 at 16:37
Without going into file system theory, the idea is that critical system daemons run as the root user and therefore, if a system-critical file system were to be really 100% full, the system would be unable to continue logging and, in some cases, unable to function at all. For this reason, maintaining a percentage of the file system for root-only writing is considered prudent. Certainly it is not a hard requirement, however, as Ignacio mentioned earlier, mke2fs maintains this behavior by default. – Tok Nov 26 '10 at 16:43
@MTilsted beacause the filesystem reserves some space (for mainteinance reasons) to user "root". IIRC by default on ext2/ext3 partitions i 5%. So normal users will see "disk full" while root can access the remaining 5%. – Mr Shunz Nov 26 '10 at 16:44
I haved added output from Tunefs. I can't really understand it. Does it say that I have less then 5% free? But should running df as root then not show the real free space available for root, instead of the 0 blocks I get now? But what you are also saying is that a process running as root have have filled the harddisk so much that even If i delete some files, it is still below the 5% and thus only root can write. That make sense(Except for df / giving 0 blocks free). I will try to delete some more files, and see if that helps. – MTilsted Nov 26 '10 at 16:49
The behavior of the df and, unasked, du utilities is probably better addressed by a separate thread. That being said, if you reference your reserved block count [430028] and your total block count [8600576] you will notice that you have reserved exactly 5% of your total blocks. Your free blocks [380030] represent only 4.4% of your total blocks. Therefore your options are to continue to remove files until you have crossed your 5% threshold, or, lower the threshold from 5% to some lower percentage. Again, it is not advisable to set this to 0% for system file systems. – Tok Nov 26 '10 at 17:04

mke2fs reserves about 5% of the disk space on a volume for root, and the amount of free space only shows user space. Remove enough files on the volume and space should free up.

share|improve this answer

Here's what I've often done to resolve this.


tune2fs -m 1 <device>

Then use something like the following to find and remove/relocate/compress the largest files:

find /mountpoint/of/device -xdev -type f -printf "%s %h/%f\n" | sort -rn -k1 | head -n 50 | awk '{ print $1/1048576 "MB" " " $2}'

Finally, once sufficient free space is available on the device:

tune2fs -m 5 <device>
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.