Data safety on Linux: Why EXT4 sucks

Aaah yes, finally we have found our way with Linux. You found the perfect distro that totally suits your needs, all the apps are in place, the desktop is tweaked and you've grown accustomed (or learned) about all the Linux quirks and differences. You are now using Linux so much you tend to forget there even exists such a thing as Windows. Sooner or later you will do what anyone does once in a while, deleting the wrong file...
No matter right? There's always the file bin, or surely some recovery tool, right?

Wrong!
"I was gobsmacked when i discovered the actual workings of the EXT4 system, i just couldn't believe data was so carelessly handled. What idiot would design such a system?"

Let's return to Windows for a brief moment, we had the FAT32 system and later NTFS. When you would delete a file in explorer it would be moved to the recycle bin. Pressing SHIFT accompanied with a file deletion command would result in bypassing the recycle bin. Let us look at that process, when we 'permanently' delete a file in Windows, what actually happens when we do that?

Simple FAT
On the FAT filesystem, the first letter of the file is changed into a lower case sigma character (σ) or 0xE5 in hex format. This in effect tells the system the disk space is ready to accept new data. It doesn't take a rocket scientist to figure out the actual data is still in place (until overwritten) and thus perfectly recoverable.

Better: NTFS
On NTFS much more information is stored about data in the form of metafiles. The metafiles are stored in the 'Master File Table' or otherwise known as MFT. The MFT holds all the information about files on the volume, timestamps, size, etc. In essence it is much like a database.
Deleting a file on NTFS simply alters the MFT. Even if disaster strikes and the MFT record has disappeared the file is still reasonably recoverable with the so called 'deep search' in many recovery tools.

The EXT way: Inodes

With the EXT file system the total partition space is divided into blocks and block groups. Each block group contains a copy of the superblock (for booting), block group descriptor table, block bitmap, an inode bitmap, an inode table and finally the actual data blocks.
Information about files and directories are stored in so called inodes (numbered). Inodes contain information such as name, timestamp, size, etc. However the most important thing to know it only contains 10 pointers to actual data, this severely limits the size, thus indirect blocks are used to extend the file size. Now this yielded much larger file sizes. Here's a visual representation:


This also illustrates the complex nature of files on the EXT system. Can you imagine what happens when the inode is lost? The data will become a total mess of information, like various books ripped apart and then stacked in random order. Luckily various tools exist to recover lost inodes.

However under normal circumstances when a file is deleted (bypassing the file bin):
  • ext marks the file's data blocks as available in its block bitmap
  • ext marks the file's inode as available in its inode bitmap
  • the number of hard links to this file is set to 0 in the file's inode
  • the deletion time is set in the file's inode
  • ext invalidates the file's name in the directory entry
So, the file's data is not actually deleted (but it might be overwritten in the future); and the crucial information in the inode (owner, access rights, size, data blocks occupied by the file and some more) is not touched. If you know the inode number, you can simply recover the file.

The bad: EXT3 and EXT4
As of EXT3 the file system became journaled, which is normally a good thing. A journal keeps records about file operations and in case of an unexpected power loss or system failure, it can tell the OS what has been done (and what was planned).
The advantage of a journal becomes clear when rebooting the system, an unjournaled filesystem needs to check the entire partition for inconsistencies and the journaled system simply checks were it was before it had shut down. A big time saver.

For no clear reason however some idiot(s) working on the EXT3 system decided it would be OK to clear the inode after a file is deleted. "Obviously this was a mistake or a bug if you like, if you ever meet someone with this actual logic it's probably a cyborg and should be shot on sight."

I find it hard to believe healthy and fully conscious humans would make such a decision (even if the journal would keep exact copies of the inodes) and thus this should be seen as a bug. If you are not a cyborg, you can file the bug here.
Linux has always been a power user platform, thus little confirmations are presented to the user, since they know what they are doing. Bugs however exist too and might accidentally delete files, thus at any given time recovery should be possible.

Conclusion

There might be a lot of big words from nerds saying how great the EXT filesystem is. Well sure, compared to FAT it might be, but compared to NTFS it isn't. IBM got it right and Microsoft improved the filesystem over the years. Of course nerds will rant saying that NTFS will defragment much more than EXT, maybe so, but is it important with SSD's taking over? As of Windows 7 mechanical hard disks are defragmented in the background, so problem solved.
NTFS is just far more mature in my opinion, because actual people and companies depend on it daily. And when shit hits the fan, there are plenty of good tools to recover lost data. If possible i would use NTFS with Linux, but that's not happening anytime soon.

When installing or using Linux just make sure you put your (/home) data on a separate EXT2 partition, to safeguard against unnecessary data loss. An alternative to this would be to create symlinks in your home directory for the most important files like Pictures, Music or whatever to a second NTFS partition. Job done!