-1

I'm asking this out of pure curiosity.

Is it possible to completely bog down an operating system by creating uncountable amount of empty files on the system partition?

In theory they have 0 bytes size, but in practice they contribute to the filesystem's metadata, as they have a name, a modification time and so on.

I once created about 6500 1-megabyte sized files to test if rsync is significantly slower when dealing with a lot of small files than with a couple of big ones. I've notices that whenever I accessed the directory that contained all the files, the file manager froze for a good chunk of time, trying to list all the files. Deleting them also took a very long while.

I wonder if this could be used to put out a cyber attack, and if one could then defend against it.

I did a small test and created 100 000 empty files with touch. That took 3 minutes 10 seconds and created a directory that is reported to be 2,1 megabytes big. Afterwards my file manager Dolphin has frozen.

Removing the whole directory with rm -rf took only 1 second.

I wonder if this could be scaled up to render an operating system unusable?

I'm running GNU/Linux (Linux Mint) with EXT4 filesystems but I wonder how different operating sys5tems and filesystems would deal with this problem.

7

In practice, there is no such thing as a "0 bytes long file". A file occupies at least an inode. Inodes have fixed size, and, more importantly, they are limited in numbers. If the inodes of a filesystem are filled up, then the filesystem is full, even if it still reports some (or even a lot of) usable space.

The impact of the above behavior to the system is minimal, however, for a number of reasons. Note that we're talking about regular users here -- if an unknown someone with root privileges can write your file system, you're screwed anyway.

Users can't fill the file system (or, to be more exact: they should not be able to), since every file system is created in a way that if it is full to a certain extent, it will report itself as full to every non-root users. How much disk space a system reserves to the root user is chosen at the creation of the file system (for ext2-4, the default is 5%). In theory, users can fill up the file system to 95% and wait for root processes (e.g. syslog) to eat up the remainder, but usually this won't happen either, since users are confined to their own disk space (or, at least, they should be), so by creating too many files, they can fill up the /home partition, which can be a nuisance, but don't cause any impact on the system at all.

File systems on servers are usually monitored along with everything else. File systems that run out of free space suspiciously fast are guaranteed to draw attention and the issue will be investigated almost immediately.

The presence of many files becomes an issue only if something is trying to read all the files, as almost all GUI programs and some text-based tools (e.g. mc) do. Simply entering the directory from the shell is usually not slow, since the files are not read then. So dealing with the situation is usually straightforward if somewhat uncomfortable.

1

As you said yourself even an empty file will consume some metadata so in principle it is possible to make a file system unusable (the details depend on the filesystem, usually you will at least be unable to write more data to it, but even deleting the files might become problematic (see btrfs), performance can degrade before you've run out of space and so on) by creating too many empty files. It should be possible to remove the files and reclaim the space used (again, the details depend on the filesystem) and restore performance. Potentially such an attack might mess with the underlying drive - if the partition is located on a ssd and is as big as the ssd it should be possible to degrade performance by using up every empty block (due to the way nand flash works this can happen long before the drive is full (the pages on the drive are grouped into larger blocks, writing directly to a page is possible only if the entire block is empty otherwise the block is read, modified and written again.. you can probably see why this degrades performance)) in theory you could also cause enough writes to actually kill the drive but this is extremely unlikely since even 2d tlc flash is much more durable than most people think ( https://techreport.com/review/26523/the-ssd-endurance-experiment-casualties-on-the-way-to-a-petabyte ).

Lacek is also correct about the fact that normal users shouldn't be able to use all the space on any partition important for normal functioning of the system if the system is configured properly so the problems they can cause should be limited.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.