Had a “huh?” moment today: a copying job erroring out with the message“no space left on device”, even though there were plenty of free blockson said disk device. What the copy process wanted to tell me of coursewas that it ran out of inodes,not free blocks.
I was copying a biggish code repository (lots of small files!) over to a8Gb virtual disk I created for testing purposes.
Usually, on bigger disks, this wouldn’t be a problem since the defaulttraditional ext3/4 Linux filesystem calculates a fixed number of inodesbased on the size of the disk — large disks, large number of files andvice versa. With the defaults, a 8Gb disk would amount to only 524288files however — my testing repository easily beat that.
The df command has the ‘-i’ switch to show the number of free inodes, eg.:
$ df -ih Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 11M 490K 9,8M 5% / udev 201K 520 201K 1% /dev tmpfs 206K 452 206K 1% /run
Other filesystems, eg.JFS, allocateinodes dynamically, but with ext4 it’s baked into the filesystem atcreation time.
For my virtual machine this was easy enough to overcome however — justadd another virtual disk, and format it with a more fitting number ofinodes. Specify ‘-i NUM’ with the mkfs.ext4 command to tell it how manybytes per inode it should use. The default is 16384; with 4096 you getfour times as much inodes.