It appears that it is possible on a network mount to set a quota on how much space a user can consume.

# edquota ramesh

Disk quotas for user ramesh (uid 500):
  Filesystem           blocks       soft       hard     inodes     soft     hard
  /dev/sda3           1419352          0          0       1686        0        0

You also can set a soft and a hard limit on how many inodes a user has.

Why would you ever need to limit how many inodes a user has access to?

Wouldn't the user still be able to fill up the disk with 1 really large file?

2 Answers 2


The reason you limit the number of inodes a user can access is so they don't make the system as a whole run out of inodes by creating a huge number of 0-byte files.

With most Linux file systems (e.g. ext3 and ext4), each file (including device files) or directory has an inode -- a number used to point to a given file/directory. If a system runs out of inodes, it doesn't matter how much free space the hard disk has; it's impossible to make a new file until inodes are freed up.

To see how many inodes each filesystem has left:

df -i

The number of inodes a filesystem has is determined by the -i argument when formatting the file system. Examples:

mkfs -t ext4 -i 1024 /dev/foo # One inode per 1024 bytes
mkfs -t ext4 -i 2048 /dev/foo # One inode per 2048 bytes
mkfs -t ext4 -i 8192 /dev/foo # One inode per 8192 bytes

The filesystem created with the -i 1024 option will have eight times as many inodes as the filesystem created with the -i 8192 option (assuming both file sytems are the same size). Sometimes, especially with some mail servers (that use "maildir") or old-school Usenet spools, one needs more inodes, since those use cases create a lot of small files.

Note that some Linux filesystems, such as Reiserfs, are able to dynamically assign inodes and do not create all of them at filesystem creation time.

  • 1
    Interesting. If it is that easy to set the number of inodes per byte, why wouldn't you always set a large inode number when making file systems?
    – spuder
    Feb 5, 2014 at 6:03
  • 2
    A filesystem with more space reserved for inodes will have less space reserved for files (I once had a Usenet spool with so many inodes, the filesystem had 30% less space than it otherwise would have)
    – samiam
    Feb 5, 2014 at 6:09

Sure, the user can fill the disk with one really large file, but that's only one vector for saturating the filesystem. The other vector is more subtle -- you can saturate the number of available inodes. In this situation df -h will still look fine, but df -i will report that you are out of inodes (and you will probably start to read a lot of "no space left on device").

$ df -i /
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/sda2      7266304 490108 6776196    7% /

At the point that you reach the maximum number of used inodes, no more inodes can be created. In many ways, this has similar symptoms as filling the filesystem with a huge file, except for the fact that existing inodes will continue to function as usual.

Restrictions on file size and the number of available inodes should be used in tandem.

You must log in to answer this question.

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