Metadata ano, malé soubory ne, ale to nemá smysl řešit na btrfs, jelikož malé soubory, menší než jeden blok, jsou stejně alokované do jednoho bloku k sobě a tím se šetří místo na disku, plus ještě máte možnost použít velice rychlou interní kompresi zstd.
S těmi metadaty se to dá provést jednoduše mkfs.btrfs --metadata single --data raidXY /dev/sda /dev/sdb /dev/sdc ..... Dle vašeho zadání bude první disk /dev/sda typu SSD a zbytek HDD, že by šlo ale následně alokovat se zpožděním metadata na zbytek HDD v poolu takto, tak to pokud je mi známo nejde.
Na prvním disku díky příkazu "--metadata single" budou alokovány výhradně metadata, ještě jde použít příkaz dup, který je bude na tomto disku duplikovat na dalším místě. Druhá věc je, že stejně pokud bude pool v RAID1/5, tak výrazně pomalejší HDD než jeden SSD v poolu, byť s metadaty na něm celkovou rychlost a propustnost výrazně nezvýší, protože ty HDD jej budou extrémně brzdit při zápisu dat na které zápis metadat musí čekat, tedy to už je vhodnější z důvodu celkové bezpečnostní architektury rovnou použít na metadata raid1/5 popřípadě XY.
Co se brždění týče: Synology teď pro metadata propaguje SSD cache ("Lock metadata in SSD cache", https://download.synology.com/download/www-res/events/Synology_2020_after_event/slides/da-dk/Session_1.pdf). Uváděné zrychlení z 15m 51s na 1m 11s hodně záleží na typu zátěže, ale i tak to stojí za pozornost.
Ano, muj dotaz je reakci na uvedeni te SSD cache - me zajimalo jak to funguje, zda to pojede i v mainline, nebo si to Syno drzi jako patch jen pro sebe.
BTRFS je moc velkej hype, umi to vsechny zazraky ale kdyz dojde na lamani chleba, se zjisti ze je to vzdy nejaky specificky pripad na ktery se nesmi sahnout jinak se to podela a sezere data :)
Mam rozpracovano SSD cache (pro EXT4), ale napisu o tom spis vlakno do fora.