Linux Ubuntu – Fix ‘No Space Left on Device’ After Resizing Partition

gpartedlinuxpartitioningUbuntu

I decided to resize the partition on my storage drive (with gparted), all seemed to go well but now when I try to create directories or copy files to the drive I get a "No space left on device" error.

Also, even if I delete some files it does not allow me to replace them.

All of the files on the drive seem to be readable just fine and I can move the existing files into other directories with no problems.

There is space on the drive.
Checking the size of all the files reports:
175,840 items, totalling 839.8 GB

It is an ext3 partition.

One wierd thing is that Ubuntu (64bit karmic) still picks the drive up as "957GB Filesystem" in the Places menu.

Note that the affected drive is not my main boot drive but simply a storage drive that I mount from the Places menu when needed.

Output of "df -h":

Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             885G  842G     0 100% /media/acd61702-ff34-460f-8539-ac762d1dc466

Output of "df -i":

Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1            58433536  175818 58257718    1% /media/acd61702-ff34-460f-8539-ac762d1dc466

I have ran "fsck -f -v /dev/sdb1":

fsck from util-linux-ng 2.16
e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

  175818 inodes used (0.30%)
    8348 non-contiguous files (4.7%)
     142 non-contiguous directories (0.1%)
         # of inodes with ind/dind/tind blocks: 76655/8046/56
222404925 blocks used (95.17%)
       0 bad blocks
      79 large files

  161176 regular files
   12907 directories
       0 character device files
       0 block device files
       0 fifos
      38 links
    1726 symbolic links (1512 fast symbolic links)
       0 sockets
--------
  175847 files

Any help would be appreciated.

Thanks,
e.

Edit:
As requested "tune2fs -l /dev/sdb1":

tune2fs 1.41.9 (22-Aug-2009)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          acd61702-ff34-460f-8539-ac762d1dc466
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype 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:              58433536
Block count:              233703571
Reserved block count:     11685177
Free blocks:              11298646
Free inodes:              58257718
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      968
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   256
Filesystem created:       Thu May 15 14:59:19 2008
Last mount time:          Fri Nov 13 13:47:23 2009
Last write time:          Fri Nov 13 14:40:32 2009
Mount count:              2
Maximum mount count:      35
Last checked:             Thu Nov 12 15:14:03 2009
Check interval:           15552000 (6 months)
Next check after:         Tue May 11 16:14:03 2010
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      793715af-66d6-46da-82aa-97ab4549b0ad
Journal backup:           inode blocks

Best Answer

Firstly, you can't simply add up the sizes of all the files on the disk, and expect that to be the total amount used. Every time you store a file, there is some space wasted. It's like putting books on a shelf, if the books vary in size, then you're going to have a space between the top of the book and the bottom of the next shelf.

Secondly, if you have any files which are open but deleted, then the space that is used will still be used until the program with that file either closes it, or exits. That's often used for temporary files, the program doesn't have to worry about cleaning them up, all it needs to do is open a file, then delete it, before working with it. These files used space will show up in df, but you can't find a filename which corresponds to it. If you want to find them, then you'll have to look in /proc/*/fd

Thirdly, and this is your issue here, ext3 file systems have a percentage of reserved space which can only be written to by root. There are two reasons for this, many file systems become inefficient when the disk becomes close to becoming full, the system has to spend more and more time fitting files into the spaces that are left. Also reading and writing to the files is slow, as they end up being badly fragmented. Another reason for reserving space for root is that it allows root to compress files and hopefully recover some space for the users. If the disk was totally full, then that wouldn't be possible.

Therefore, there is nothing wrong, what you are seeing is normal behaviour for a full disk.

Related Question