Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the

Personally, I'm not against file extensions, and I like to see and use them, however when something (i.e. magic bytes of a file) is used a lot system-wide, the underlying mechanisms optimize towards the use case as a natural tendency. The interesting, or more accurately neat thing about EXT family of filesystems is, the file header is always one pointer away from your inode structure for that file. With NVMe disks or SSDs in general, this is a very cheap operation, even when done en-masse. Even when we were using HDDs, anti-fragmentation features of EXT3/4 kept that one seek pretty cheap. As a test, I fed my whole documents folder (~3500 files) into "file" tool to see what it does (via "file -f $filelist"). It finished in ~1,5 seconds. I redirected the output to /dev/null to eliminate the overhead incurred by printing things over SSH, though. While everything is fast for small n, the consideration of small for this operation goes a long way, AFAICS. Oracle has a great write-up about EXT4 and its structure: https://blogs.oracle.com/linux/understanding-ext4-disk-layout-part-1 https://blogs.oracle.com/linux/understanding-ext4-disk-layou...