Once in a while, less than once per year, I check if ext4 inline data is ready for use yet. It's been available for a decade or so now. In theory.

It's pretty cool, it can fit small files inside the inode as an extended attribute instead of using up a whole disk block. If you have many files (and directories, remember that directories are files too) that are much smaller than 4 KiB, this can mean both a space savings and a performance improvement, as you've already read the inode and can skip the seek to the data block.

What I do is I create a fresh ext4 volume in a loopback file, with a large inode size and -O inline_data, and then I clone my pictures git repo to it. On a normal ext4 it uses 3 GiB when checked out. 1 GiB is the git packed data and 2 GiB is the checked-out data. I only do a git clone and don't sync the git-annex data, so that leaves out the 400 GiB of git-annex blobs, the actual pictures and movies.

So today I ran the test again. On a fresh Debian bullseye I created two loopback volumes in a sparse file each, one with -I 512 and one with -I 1024.

I cloned my repo into the one with inode size 1024. Most of the 600 000 or so symlinks that I briefly sampled, all of my JPG file symlinks, used 0 bytes of data blocks, meaning the data was stored in the inode. Many directories also used 0 bytes. Cool! The disk image used 1 GiB on disk, for the inodes and for any data blocks. Also cool!

I think most of those symlinks should fit even in a 512-byte inode, as it would fit a 384-byte file and at a quick glance most of those symlinks are slightly over 200 bytes.

I cloned my repo into the volume with inode size 512. After a few minutes the OS froze.

ext4 inline data is not ready for use yet. Let's check again in a few years.

#ext4 #inlineData #ext4inlineData