Linux Filesystems – How to Optimize for Lots of Small Files

Most likely neither. The size displayed by ls is the length of the file, however most modern filesystems support "Sparse Files" where empty blocks are not actually written to disk. Try running du -h /ssd/* and see what size it reports the files as. 'du' will display the amount of disk actually used, which should be fairly close (excluding filesystem overhead & reserved blocks) to that reported by 'df'.

First, the conversion process saves a copy of all the prior system metadata in the new metadata, which can take up a substantial amount of space on large drives.

Second, the conversion process is messy, resulting in extremely large extents, since the extents in EXT4 are also large, and BTRFS will inherent their size.

The allocated size becomes approximately 1.5X the size of the used metadata size. The defragmentation process will reduce the size of the used metadata, but does not change the allocation. There is also a skinny extents option to further reduce metadata, but this is more helpful on systems with large amounts of small files; your metadata allocation less than a 10th of a percent, which is very small.

The balance command IS supposed to reduce the allocation size to a new value based on the current metadata usage, which it seems to have done correctly. The balance command is not supposed to move from metadata to data, but that may have something to do with the original EXT4 metadata image copy being in the original metadata allocation, and now moved into data (ext2_saved subvolume). Check the size of the EXT4 image to see if it is 1.1TB. Regardless, I would defragment the filesystem.

It should be noted that running balance without defragmentation can result in errors. Newer versions of the kernel are recommended to prevent filesystem problems, specifically 3.17 and later.