A friend of mine who likes programming in the Linux environment, but doesn't know much about the administration of Linux recently ran into a problem where his OS (Ubuntu) was reporting "out of disk space on XXX volume." But when he went to check the volume, there was still 700 GB left. After much time wasted, he was eventually able to figure out that he was out of inodes. (He was storing lots of little incremental updates from a backup system on this volume and burned thru all his inodes.)

He asked me why the Linux kernel reported the error message ("out of disk space") instead of properly reporting ("out of inodes"). I didn't know, so I figured I would ask StackExchange.

Anyone know why this happens? and why it hasn't been fixed after all these years? (I remember a different friend telling me about this problem in 1995.)

2 Answers 2


A single error number, ENOSPC, is used to report both situations, hence the same error message.

To keep compliance with the ISO C and POSIX standards, the kernel developers have no choice but to use a single error number for both events. Adding a new error number would break existing programs.

However, as sticking to traditional error messages is not AFAIK mandatory, nothing should forbid a developer to make the single message clearer, like for example out of disk/inode space

Technically, whether being out of inode space or out of data space is the same, i.e. it means there is not enough free disk space for the system call to succeed.

I guess you weren't going to complain if your disk is reported as full while there are still free inodes slots.

Note that file systems like JFS, XFS, ZFS and btrfs allocate inodes dynamically so do no exhibit this issue anymore.

  • Recent filesystems include ext4? Jan 15, 2014 at 4:42
  • @CamiloMartin I don't think it does.
    – jlliagre
    Jan 15, 2014 at 7:02
  • @CamiloMartin Unfortunately no, ext4 allocates inodes at fs creation time like ext2/3 and can not be modified later.
    – Matt
    Jan 15, 2014 at 8:21
  • @mindthemonkey Darn! That's probably some backwards-compatibility thing, I guess. What other filesystem has nice features but is stable enough (is btrfs stable)? ext4 seems to be some sort of "default choice" (at least from my novice perspective). Jan 16, 2014 at 17:33
  • 1
    Yeah ext's have always been extensions of the previous version and backwards compatible so no major changes but that means it's remained fairly solid and stable. I personally do all my large volume storage on freebsd boxes with ZFS. BTRFS is still considered "unstable", although most distributions will at least let you use it.
    – Matt
    Jan 16, 2014 at 19:17

I assume your friend is using an ext fs, because its one of the few sensible fs that can run out of inodes.

It would appear your friend either fiddled with his filesystem and broke it or has a ridiculously large volume of several TB. Inodes are not a use-once-and-throw away thing. If he really ran out of inodes it means he has ridiculously many files and directories ... which can happen on a >4TB (educated guess) volume, where "only" 700GB are free. For the ext family of fs the number of inodes is determined when the fs is created. From the mkfs.ext4 man page:

-i bytes-per-inode
          Specify  the  bytes/inode ratio.  mke2fs creates an inode for every bytes-per-inode
          bytes of space on the disk.  The larger the bytes-per-inode ratio, the fewer inodes
          will  be  created.  This value generally shouldn't be smaller than the blocksize of
          the filesystem, since in that case more inodes would be made than can ever be used.
          Be  warned  that  it is not possible to expand the number of inodes on a filesystem
          after it is created, so be careful deciding the correct value for this parameter.

To shorten the remainder of this answer: This means mkfs is either provided with such a ratio, or it will assume one. If your friend uses the fs differently than assumed the chosen ratio may be wrong for his use case and he gets that error ... filling up a single multi-TB volume with tons of small files may count as such.

Does your friend use some desktop environment that implements the concept of a "trash can" for files or any other forms of backups that may create large amounts of files? Maybe he can fix his problem by simply getting rid of unneeded files.

I remember this issue with ext2 from about the time when kernel 2.4 was fairly new. As a rule of thumb, I always use XFS for volumes that are very large compared to what is currently common. Currently I'd call everything between 250GB to 1TB common for a single volume and we can buy 4TB HDDs. So for everything >3TB I'd rather use XFS than ext. Just a rule of thumb, but haven't run out of inodes for a long time ...

  • 1
    I'm afraid you are not answering to the question asked.
    – jlliagre
    Jan 15, 2014 at 0:20
  • True. I was sort trying to answer the first inline question I hit "Anyone know why this happens?", but not the one in the title.
    – Bananguin
    Jan 15, 2014 at 12:48
  • Right. My friend knows what happened. He was doing some sort of backup system where it was storing incremental changes UNcompressed (nor TAR'd) so that there were all these tiny little files taking up space. I don't think he ever had such a large FS previously, so running out of inodes was a new thing for him. Ergo, he was frustrated when he typed "df -h" and thought, "huh, I still have a ton of space left" -- Frankly, I agree with him. For the kernel to say "out of space", when in fact it should have a separate message "out of inodes" is very confusing.
    – Pretzel
    Jan 19, 2014 at 5:28
  • @Bananguin -- Do you know what the default byte/inode ratio is?
    – Pretzel
    Jan 19, 2014 at 5:34
  • @Pretzel: I think I remember that the default is one inode for each 4k. I just checked my computer (tune2fs -l /dev/sda1) and I happen to have a ratio of 1 inode for every four blocks and every block is 1k in size. How much this can be considered "default" however, I do not know.
    – Bananguin
    Jan 19, 2014 at 14:18

You must log in to answer this question.

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