Odpověď na názor

O ty ostatní zmíněné výhody XFS (alokační skupiny, lepší paralelismus, škálování atd.) až tak nejde.
Ten primární důvod je pevný počet inodů (prealokované místo) u ext4, kde se to specifikuje jen při vytváření filesystému (většinou jako poměr - např. "mkfs.ext4 -i 4096" vyhradí pro každé 4 kilobajty dat jeden bajt na inody, default je myslím 16k).
Za normální situace každý soubor, adresář nebo symlink spotřebuje jeden inode.
S tím S3 serverem tam je ale ještě další vrstva, která větší soubory rozděluje na chunky (což může být např. 1 megabajt, nebo něco jiného podle potřeby). Na filesystému pod tím je pak každý chunk uložený jako samostatný soubor, takže ta spotřeba inodů může být výrazně větší, než když se to ukládá rovnou.
Je to asi primárně záležitost větších úložišť, ale ovlivňuje to i zvolená velikost chunku, délka ukládaných souborů, nastavení při vytváření fs atp. Dá se pak také samozřejmě dopočítat, kdy by to byl problém, resp. kolik inodů se na daný systém vejde.
XFS.. pak má dynamickou alokaci místa na inody, tzn. prakticky to pevné rozdělení vůbec nemusíte dopředu řešit, proto to doporučení.

Jinak CoW filesystémy jako Btrfs nebo ZFS mají také dynamickou alokaci inodů, ale obecně mnoho jejich výhod v tomhle použití trochu padá tím, že je nad fs další vrstva, kde se také počítají checksumy a redundance je v tomhle případě řešená replikací celých souborů resp. chunků na jiné nody.
U RAIDu pod tím je to pak nejspíš na zvážení podle použití..
Pokud tam bude a dojde k výpadku jednoho z disků, tak ten node kompletně pojede dál v degradovaném režimu a po výměně bude citelně rychlejší rebuild (data se berou lokálně blokově), na druhou stranu zas přijdete o místo.
Pokud použijete multi-disk v Garage, tak bude mít víc místa, ale zároveň když nastane výpadek, vyměníte disk, vytvoříte fs a připojíte jej do stejného adresáře, tak se všechny chunky budou zpátky kopírovat po síti, aby se doplnil nastavený počet reundantních kopií.

Finálně při těch uvahách o rychlostech je třeba brát v potaz také to, že pokud mám např. tři nody a na jeden kontinuálně zapisuji (např. v rámci LAN, nebo jednoho serveru s virtuály, kontejnery), tak se ty chunky musí dostat na zbylé dva nody.. a teoretická rychlost uploadu se pak dělí dvěma.
U krátkých zápisů (co jsou menší než nastavený buffer) mu stačí potvrdit zápis jen z jednoho dalšího nodu, aby si splnil kvórum, a do třetího (nejpomalejšího) pak zapíše asynchronně. Ale když do toho budu kontinuálně hrnout data, naplní se ten buffer a v podstatě pořád čekám na oba dva. Další faktor, co v tom hraje roli, bude pak samozřejmě i latence sítě mezi nody.