Har ni via synologys ssh-terminal gjort några grundläggande skriv och lästester mot filsystemet ännu ??
Har ni kolla med 'dmesg' (som root) om det är någon disk som flaggar för problem - en disk som börja knöla i sin RAID kan ge oerhörda problem med prestanda utan att det syns i SMART eller ge några uppenbara felrapporter.
---
Enkla grundtester avseende läshastighet kan göras med 'dd' (i terminalförnster)
tex. enkel ren lästest av en fil i lagringen:
dd if=/path/fil_i_flera_GB-Storlek of=/dev/null bs=1024k status=progress
som ger svar liknande:
"
510+1 records in
510+1 records out
534818816 bytes (535 MB, 510 MiB) copied, 0,49767 s, 1,1 GB/s
"
och där 'path' är sökvägen till mappen där du normalt lägger dina filer över nätverket
För enkel test av skrivhastighet liknande:
"dd if=/dev/zero of=/path/zerofile bs=1024k count=1024 status=progress"
och man får tiden det tar att skriva 1 GB stor fil.
ändra värdet på 'count' för antal 'bs-block' för mindre eller större filer.
utelämnar man 'count' så skriver det tills lagringen är full eller avbryts med Ctrl-C
helst bör man prova med fil mycket större än NAS:ens RAM-minnesmängd då Linux som snurrar i denna är rätt bra på att cacha data innan skrivning och det upplevs som snabbt vid mindre filers skrivning.
glöm inte ta bort 'zerofile' efter övningarna med 'rm /path/zerofile'
- även om filen är fylld med bara '0' så tar det fortfarande diskplats...
Är skriv och läshastighet en bit över 100 MB/s även vid en större filers läsning/skrivning så är inte lagringen flaskhalsen utan det är andra saker som har knorr på sig
Ibland - speciellt i äldre NAS har man en busybox-version av 'dd' och den är så strippad att den kan inte rapportera någon status eller skriver något om hastighet.
Där får man köra 'time dd xxx ' för att få reda på hur länge programmet körde och sedan dela filstorleken i antal sekunder programmet körde för att få skriv/läshastigheten.
'time' ger 3 tidsvärden - total körtid, systemtid, och användartid i form av tid för upptagna systemresurser.
---
En väldigt användbart systemmonitor-program att köra via ssh om den går att installera i Synology är 'atop' och lämplig kommando är då 'atop -fF 1' (som root) på så stor terminalfönster du kan avvara - där ser du många saker på en gång och en av dem att titta på är disk-busy och hur fort det skriver och läser på diskarna - svarstider etc. och den vägen kan få en hint om hur diskarna och RAID fungerar tex. när stora filer skrivs - visar också nätbelastningar på nätverk mm.
---
Om filsystemet skulle ha dålig prestanda så kan det beror på flera orsaker.
En att man har slagit på filsystemkompression på BTRFS - är det bara fåtal processorkärnor så kan det få påverkan då kompression är alltid CPU-tung även om det fördelas på flertal CPU-core. I BTRFS går det att välja mellan flertal kompressionsalgoritmer och hur hög kompressionsgrad dessa kan ställas in för - hög kompression = långsam, låg kompression = snabbare. Om man fortfarande vill ha mapp/filsystemkompression men inte lika kostsam som default så skulle jag prova med 'zstd' och kompressionsgrad 1 då det fortfarande biter ordentligt på 'luftiga filer'.
Det andra är att BTRFS är en COW-flsystem och med detta är det inbyggt i sig att de fragmenterar sig med tiden, normalt så sköts det betydligt bättre än tex. NTFS när det ligger på snurrdisk och i de flesta fall är inget man behöver tänka på
BTRFS har verktyg på kommandonivå att kunna göra defragmentering både för sin egna metadata, på enskilda filer och hela filträd och märker man att det är trögt så kanske man skall kika på dessa och börja med att defragmentera metadatat och därefter enskilda filer eller mappträd med filer som man vill få snabbare överföring.
Dock defragmentering kan få konsekvenser i form av att diskutrymme försvinner på NAS:en om man har snapshot-kopior i form av subvolymer av orginal-volymen (tex. automatisk bakgrundssnapshot av dina synliga nätverksvolymer) av aktuella filer som från början delar samma datautrymme som orginalet, men efter defragmentering av orginalet så blir dessa individuella filer i större eller mindre grad med sin egna dataset som tar diskutrymme - beroende på hur mycket som stuvades om på orginalfilen man gjorde defragmentering på.
Sedan fins det en ytterligare 'defragmentering' att packa ihop halvtomma 'chunk' i 1GB block över diskytan som BTRFS har som lägsta nivå och låta de nybildade ompackade chunken placeras närmare början (ytterkanten) av disken (där snurrdisken är snabbare) och den vägen minska på huvudrörelsena vid sökning och läsning/skrivning av filer. - detta görs med 'balance' (balance kan gör mycket mer än så inklusive att göra olika RAID-strukturer om BTRFS-volymen har direktaccess till flera fysiska diskar eller logiska LVM volymer)
Slutligen - om du aldrig gjort sådana övningar tidigare som defragmentering och 'balance' så är det bra att ha en backup på allt i NAS:en i fristående lagring eller i en molntjänst ifall det skulle skita sig - det bör du ha oavsett, så ha du det inte nu så bör du snart som möjligt få till det.
Nu har det aldrig hänt mig att det skiter sig bara för att man kör defrag eller balance på BTRFS, men om det ändå skulle framkalla trassel för att man kör det[1] och tex. latenta fel på någon eller flera diskarna blir synliga - så är det bra med en backup vilande någonstans...
[1]
Särskilt när det ligger på en LVM-RAID i Synology - jag har den bestämda uppfattningen att mdadm-RAID och LVM(2) är större trubbelmakare som kan generera totala filsystemkollaps och filförluster[2] än vad BTRFS inbyggda RAID-hanterar gör trots att den inte är riktigt 'färdig' - dvs. någon står som garant att den är 'klar'
[2]
Speciellt efter multipla strömavbrott med korta tider mellan så att synkningen mellan diskarna lagom kommit igång av LVM/mdadm-RAID innan nästa strömavbrott - det är då det lätt blir korruption, speciellt om diskarnas skrivcache är påslagna då dessa numera rymmer mycket data i väntan på skrivning och förloras vid strömavbrott och det blir en jävla röra.
