35

It is well-known that empty text files have zero bytes:

enter image description here

However, each of them contains metadata, which according to my research, is stored in inodes, and do use space.

Given this, it seems logical to me that it is possible to fill a disk by purely creating empty text files. Is this correct? If so, how many empty text files would I need to fill in a disk of, say, 1GB?

To do some checks, I run df -i but this apparently shows the % of inodes being used(?) rather than how much they weigh.

Filesystem             Inodes  IUsed    IFree IUse% Mounted on
udev                   947470    556   946914    1% /dev
tmpfs                  952593    805   951788    1% /run
/dev/sda2            28786688 667980 28118708    3% /
tmpfs                  952593     25   952568    1% /dev/shm
tmpfs                  952593      5   952588    1% /run/lock
tmpfs                  952593     16   952577    1% /sys/fs/cgroup
/dev/sda1                   0      0        0     - /boot/efi
tmpfs                  952593     25   952568    1% /run/user/1000
/home/lucho/.Private 28786688 667980 28118708    3% /home/lucho
Zanna
  • 3,571
luchonacho
  • 823

5 Answers5

39

This output suggests 28786688 inodes overall, after which the next attempt to create a file in the root filesystem (device /dev/sda2) will return ENOSPC ("No space left on device").

Explanation: on the original *nix filesystem design, the maximum number of inodes is set at filesystem creation time. Dedicated space is allocated for them. You can run out of inodes before you run out of space for data, or vice versa. The most common default Linux filesystem ext4 still has this limitation. For information about inode sizes on ext4, look at the manpage for mkfs.ext4.

Linux supports other filesystems without this limitation. On btrfs, space is allocated dynamically. "The inode structure is relatively small, and will not contain embedded file data or extended attribute data." (ext3/4 allocates some space inside inodes for extended attributes). Of course you can still run out of disk space by creating too much metadata / directory entries.

Thinking about it, tmpfs is another example where inodes are allocated dynamically. It's hard to know what the maximum number of inodes reported by df -i would actually mean in practice for these filesystems. I wouldn't attach any meaning to the value shown.

"XFS also allocates inodes dynamically. So does JFS. So did/does reiserfs. So does F2FS. Traditional Unix filesystems allocate inodes statically at mkfs time, and so do modern FSes like ext4 that trace their heritage back to it, but these days that's the exception, not the rule.

"BTW, XFS does let you set a limit on the max percentage of space used by inodes, so you can run out of inodes before you get to the point where you can't append to existing files. (Default is 25% for FSes under 1TB, 5% for filesystems up to 50TB, 1% for larger than that.) Anyway, this space usage on metadata (inodes and extent maps) will be reflected in regular df -h" – Peter Cordes in a comment to this answer

sourcejedi
  • 50,249
  • So, are you saying that if I create 28786688-667980=28118708 empty files, I will in effect run out of inodes and "break my system"? – luchonacho Jul 13 '17 at 19:42
  • 2
    XFS also allocates inodes dynamically. So does JFS. So did/does reiserfs. So does F2FS. Traditional Unix filesystems allocate inodes statically at mkfs time, and so do modern FSes like ext4 that trace their heritage back to it, but these days that's the exception, not the rule. (Unless you weight things by installed-base, in which it's probably accurate to say that most of the filesystems currently on disk on *nix systems in the wild have statically allocated inodes.) – Peter Cordes Jul 14 '17 at 01:30
  • BTW, XFS does let you set a limit on the max percentage of space used by inodes, so you can run out of inodes before you get to the point where you can't append to existing files. (Default is 25% for FSes under 1TB, 5% for filesystems up to 50TB, 1% for larger than that.) Anyway, this space usage on metadata (inodes and extent maps) will be reflected in regular df -h, @luchonacho. – Peter Cordes Jul 14 '17 at 01:34
26

Creating empty files involves using the following:

  • inodes, one per file;
  • additional directory entries, also one per file, but aggregated.

The number of available inodes is often determined when a file system is created, and can’t be changed (some file systems such as Btrfs or XFS allocate inodes dynamically). That’s what’s measured by df -i. When you run out of inodes, you can’t create new files or directories, even if you have disk space available.

Directory entries take up space too, from the available disk space. You can see this by looking at the size of a directory: it’s always a multiple of the block size, and when a directory contains lots of files, its size grows. If you run out of disk space, you may not be able to create new files or directories in a directory which is “full” (i.e., where adding a new file would involve allocating a new block), even if you have inodes available.

So yes, it is possible to run out of disk space using only empty files.

Stéphane Chazelas
  • 544,893
Stephen Kitt
  • 434,908
  • So I would need to create enough empty files to arrive to 100% usage of inodes? – luchonacho Jul 13 '17 at 19:43
  • @luchonacho yes, effectively one empty file per inode. – Stephen Kitt Jul 13 '17 at 20:55
  • Also note extended attributes that can add space on top of that. For instance, if the directory has a lot of default ACLs, creating a file in it will need space to store those ACLs. – Stéphane Chazelas Jul 21 '17 at 11:09
  • OK,I stand corrected. Thing is, it looks weird to me both with the rendered and fixed-width fonts on my browser. Out of curiosity, how do you insert them? Does your keyboard have a different key for that character and the U+0022 one? – Stéphane Chazelas Jul 21 '17 at 12:17
  • Thanks, out of curiosity, I checked if they were on my UK keyboard layout and indeed they are on AltGr+Shift+V/B (double quotes without shift). I'll stick with U+0022 though. – Stéphane Chazelas Jul 21 '17 at 13:40
7

Pure logic argument:

A file name consists of a non-zero amount of bytes. Even with theoretical maximum compression in a hypothetical file system designed to allow the absolute maximum amount of file names, each file name will still consume at least one bit somewhere on your physical disk. Probably more, but "1 bit per file" is the trivial minimum.

Calculate the amount of bits that can possibly fit on your platters, and that is a theoretical maximum number of (empty or non-empty) files you can store on it.

So, the answer is yes. Eventually, you will run out of space, no matter what storage you are using, if you keep adding empty files. Obviously you will run out much sooner than the maximum calculated in this fashion, but run out you will.

AnoE
  • 575
0

Simply no but you can run out of the inodes on linux which will be the same as running out of the space.

you can try something like this in your shell n=0; while :; do touch $n; let n=n+1; done

Just make sure to run it in the virtual machine or you will be out of inodes very fast.

MarkoShiva
  • 302
  • What is that command doing? – luchonacho Aug 08 '17 at 05:57
  • It start while true infinite loop which in every turn creates a file name that is an integer starting from 0 then 1 2 3... it will eventually create enough files to use all of inodes of the filesystem. – MarkoShiva Aug 09 '17 at 07:37
  • 1
    If run that command on your /home partition if it is independent then / partition you will not have problem you just couldn't write anymore to your /home partition. My suggestion make a directory named inodetest cd into it and then run command after you see errors that you cannot anymore create files in the filesystem press ctrl+C and run rm -fr inodetest to get rid of all of those empty files and work normally again. :) – MarkoShiva Aug 09 '17 at 07:43
0

You can't fill-up the disk by making empty files - the disk will still have plenty of space for new files. But yes, you can exhaust the filesystem's finite supply of free inodes - at which point you can't create new files (even though your disk - as far used space go - are practically empty). It's just the filesystem's list of inodes that's all been used, not the disk... so the filesystem is full, while the disk is practically empty. The inode-table use space on the disk, but the table doesn't grow when you add files - just as a sheet of paper doesn't grow when you write on it's lines.

(an answer-in-a-comment by Baard Kopperud)

luchonacho
  • 823