Nu vet vi inte hur stora datamängder som körs över per gång - om det är läs eller skriv.
Om man ser hur bcache jobbar så bidrar det nästan inget alls vid stora filöverföringa utan specialiserar på att cacha få-sektorssökningar i stor mängd men bypassar långa sekventiella skrivningar/läsningar. Det har också göra att inte bränna ut en SSD på för kort tid om man inte tänker sig använda server-SSD som tål flera fulla skrivningar per dag och inte tappar fart efter 10-30 GB som dagens konsument-SSD/NVMe när SLC-cachen tar slut vid en stor överföring.
Själv har jag bränt mig som fasen med just bcache - tror inte att just bcache var problemet utan just använda SSD som sa upp sig efter ett tag med den användarmönster jag hade (deduplicering av hårddiskar) och har man write-back aktiv så förlorar man filsystemet till ej räddningsbart status när det sker - det är riktigt allvarligt!!
Skall man gå på SSD-cache, kolla noga med grymt jobbiga test-case innan och det värsta jag hittat hittills är deduplicering av rätt full BTRFS-filsystem med bunt ganska lika diskimages med 'bees' - har provar tre olika fabrikat SSD - ingen överlevt efter något dygn och det verkar vara deras interna TRIM-tabeller som trasslar ihop sig fullständigt att SSD till slut stannar helt (långa timeout att kärnan till slut kastar ut SSD)[2]
---
Utesluter här att nätverksportarna anses vara flaskhalsen - annars är det där det ofta flaskar och man behöver fler parallella portar eller att de går med högre bitrate (10 Gigabit Ethernet till en router/switch med dito ingång som sedan fördelar ut)
SAS-gränssnittet är 1200 MB/s vilket ger utrymme för flera diskar (via SAS-expandrar) innan kanalen blir full - dessutom kan SAS köra i duplex.
Om det är synology med expanderlåda med antal diskar i så gissar jag att SATA3 (600 MB/s) som förbinder mellan enheterna och är flaskhalsen kapacitetsmässigt och SATA kan heller inte köra i duplex [1]. Det räcker idag med 2 st 10 TB-diskar för att den bussen skall vara full och det blir reducerad fart om man skall hantera 4 eller 6 diskar parallellt i expander-burken som vid tex. resynkning av diskar.
Har man identifierat denna länk mot expander som den egentliga flaskhalsen kapacitetsmässigt så är förmodligen möjligheterna med Synology uttömda och det är dags att titta på riktig server som är byggd för driftsäkerhet och med diskkontrollerkort med strömavbrottskyddad RAM-cache som har dual-port SAS3 - och förstås dito diskar - dessa kan också länkas vidare till expander-burkar med en eller flera SAS3-länkar parallellt om det är diskplats som är det viktiga.
[1]
SATA har också 2 par men dessa är låsta för data i respektive riktning, SATA kan heller inte köra i duplex vilket innebär att läsning och skrivningar måste köas efter varandra medans SAS kan läs och skrivningar köras parallellt (full duplex) och i senare SAS-standard också använda båda paren dynamiskt för skrivning eller läsning med tillsammans dubbla farten (2400 MB/s) och med dualport nå 4800 MB/s i länken till tex en SAS-expander låda med diskar.
SAS har också default bättre dataskydd på sina överföringar än SATA och vi pratar om förbättring av 10000 lägre risk för oupptäckta överföringsfel gentemot SATA-bus. Och så fort man börja använda expandrar och därmed längre datakablar så ökar alltid risken för överföringsfel av olika slag.
[2]
SSD är otrolig långsamma och sega efter 'händelsen' och går knappt att skriva någon större mängd slumpmässig data innan de i princip stannar helt igen - för att de skall bli användbara igen måste man göra zerofill från första till sista sektorn - om möjlig köra blkdiscard (nästan som en security erase men skapar ingen ny nyckel) och i fallet med Samsung 830 har inget av det fungerat och håller på och hänger sig och ha sig även efteråt så sista försöket är att göra en security erase på denna, annars verkar den blivit brickad av bcache-testet.
