Hi everyone!

I hope I write in the right forum.

I recently had a problem with my ext4 filesystem. Let's start from the beginning.

I had to write some program in Java (everything was compiled with the Oracle Java) and by mistake my program did the following:

• read one byte from the source file
• create a file (like dest0) and write that byte
• read the next byte from the source file
• create a file (like dest1) and write that byte
• and so on...

By the time I realised that I made something wrong so many files were created that it was not possible to delete them simply with

Bash complained that the command line was too long! I had to use

and it took a lot of time.

I could delete all the dest* files, but the filesystem seemed to be damaged after that.

Even though listing the content of the directory where the dest* files were create just showed sort of 10 items (files or directories), some programs took ages to list the content.

The I run first a fsck.ext4 and then a fsck.ext4 with the -D option (optimizes directories in filesystem), and it turned out that there was a "directory hole".

In principle, a directory in the ext4 file system can contain a quite huge number of files and I do not think I reached that number.

In any case the file system should not have been damaged just by this.

Does anyone know what could have happened?

My distribution is Linux Mint 17.2 Rafaela, with the default kernel 3.16.0-38-generic #52~14.04.1-Ubuntu SMP. I used e2fsck 1.42.9 (4-Feb-2014).

Thank you for your answers!

probably you can try:
to see what is inside.

The content is actually fine now.

My question is another one: why did that happen? Why did the kernel not crash the program instead letting it corrupt the file system?

You probably created the problem by trying to create thousands of files in a single directory. If you know that you are going to create a very large number of files, you should arrange for a directory structure to partition the collection in some reasonable-to-you way.

Yes, but it seems that ext4 has not particular limitation about the number of files or directories in a given directory. The only limit is global (as far as I understand) and in the use of inodes.

https://kernelnewbies.org/Ext4
https://en.wikipedia.org/wiki/Ext4

My program should have been stopped because there were no more inodes instead of damaging the file system.

I would then encourage you to open a trouble-ticket with the Linux developers. It would probably be most informative to them if you could construct a test-script which (in a freshly-made VM, of course ...) consistently replicates the problem using a current distro. (i.e. "install a brand-new Linux on a brand-new VM, run this script, and 'presto, every single time.'")

Directories support a number of file entries in a single-level list. As you add more files, the number of blocks and the complexity of the inode structure grows. Your directory structure is probably huge, with all of the middle entries empty. To fix this, create a new empty directory (mkdir), move the files from your old directory to the new directory (mv), delete the old directory (rmdir), then move the new directory to the old name (mv).

But if, as the OP suggests, a filesystem data-structure error was produced by what s/he did, then this probably should be reported as a bug i-f it is readily reproducible.

Thank you all for your answers. I will try to contact the people that develop ext4 and I will let you know!