USB-stacken är som den är och under tex windows är det mycket overhead för var transaktion av data som skall startas - och samma sak ser man i Linux där det knappt går under 0.25 ms genomsnittlig söktid även när det tutar mot en snabbare eSSD som samsung T7, och låg runt 0.07 ms när jag körde mot den här datorns NVMe [1] . På en extern 10TB USB-disk med på insidan Seagate Barracuda PRO (ej SMR) så var genomsnitt söktiden 13.06 ms, snabbast ca 260 MB/s, långsammast 162 MB/s och genomsnitt 221 MB/s. - alla tagna med gnome-disks, där är inte USB:s transaktionstid den dominerande tidstjuven utan det mesta ligger på disken själv, men ju snabbare lagring, ju mer kommer USB:s transaktionstid påverka den totala överföringshastigheten.
I NAS har man sällan behov av snabba diskar om det är för ren bulklagring då nätverket är i sig en flaskhals både i fart och i transaktionstider, och en NAS med tex. ubuntu som headless server och anständigt med RAM-minne så kan saker går väldigt fort även med snurrdiskar (tom. utan skriv-cache aktiv pga. HW-RAID1 i mitt fall) då Linux RAM-cachar och saker som tex. metadata för filsystemet klistrar sig kvar i RAM väldigt länge och utkonkurreras ogärna av andra programs RAM-begäran och tex. filsökningar med 'find' går snorsnabbt om det har gjorts något sådant tidigare senaste dygnen. - med snorsnabbt menar jag > 1 miljon filer och hundratusentals mappar i filsystem med djupa filträn på 1.2 - 2.5 sekunder - alltså _hela_ diskens alla filer... (kör BTRFS) ni som stänger av filindixering i windows för att den gör datorn slö, förstår att detta är inte en helt oväsentlig del när saker bevisligen kan göras effektivare och dessutom med linux 'find' är det alltid på live-data i filsystemet som det söks på och inte någon utdaterad filindex.
Om NAS också är tänkta att ha databasmotor etc. så är förstås en SSD/NVMe-lagring ett bättre alternativ men ofta byggs det som hybrid-system med lågrörlig och kall data läggs som bulklagring på snurrdiskar medans det som kräver mycket transaktioner på kort tid läggs på SSD/NVMe.
Och till sist, NAS är upptids-säkring - inte datasäkerhet även om du har redundanta lagringar i denna - se till att ha en regelbunden körd backuprutin till annan fysisk/molntjänstbaserad oberoende lagring och också kan hantera läget om all din data i din NAS har blivit krypterad av en skadlig malware/ransomware och sedan har gått iväg som backup i x antal veckor oupptäckt - dvs. generationsbaserad backup/molntjänst och inte bara en spegling som bara skrivs över av den senaste versionen.
[1]
och den varierade kraftigt i läshastighet mellan 1.1 och 2.2 GB/s och det syntes mycket väl vilken partition jag använder sällan (windowspartitionen) och partitionen som används mest hela tiden (linux-partitionen) och det är en SKHynix_HFM512GDHTNI-87A0B och är tydligt att det inte är bara är Samsung som har prestandaeffekter av spänningsglidning och därmed långsammare läsning när datat har legat i träda en längre tid utan access eller omskrivningar.
Det är också tydliga trappsteg mellan 0, 1 och 2 iterationer av Viterbi eller LDPC innan datat läses felfritt och vidare leverans till host (vid ~12 iterationer och högre blir det inte någon datakvalitetsförbättring längre och klarar det inte att läsa ut felfri data längre så gäller det att de finns en 2:nd nivå felrättning med Reed-solomo-kod och det kan skilja sig mycket mellan olika SSD/NVM-märken om de har det eller inte då 2:n nivå ECC:s paritet tar också plats räknat i flash medans 1' nivån är oftast redan integrerad i själva flash-die:a ...för sin egna överlevnad som flashlagring. - man kan säga såhär - hade Samsung inte haft sin 2'-level RS-ECC på sina 840-SSD så hade de varit borta från SSD-marknaden idag, men jag vet att typ Sandisk inte har sådan andra lager av ECC på den SSD som fick bitrot efter 11 månader i skrivbordslådan.
- Folk skulle bara veta hur vingligt dagens data lagras i moderna flashmedia och utan Viterbi/LDPC på bitströmsnivå vid läsning och BCH-felrättning på 1'lagrets ECC direkt på chip-die så skulle det inte vara många bytes sekventiellt efter varandra vara rätt när det läses från råa flash-block.
Andra lagret av ECC behövs när första lagret misslyckas - den typen av dubbel-lager har använts på CD/DVD och på BR används också Viterbi på bitströmmen efter läshuvudet innan ECC-rättningen, så man kan säga att det är rätt vingligt med mycket bitfel även på optisk media, och samma sak kan sägas om snurrdiskar då de också har Viterbi/LDPC för signalförbättring och BCH-kod ECC för de kvarvarande bitfelen. På enterprise-snurrdiskar som Seagate Cheetah har man typ 30% extra Reed-Solomo paritetskodning ovanpå allt också och klarar multipla sektorförluster och hela cylindrars bortfall - och då jobbar dessa diskar fort med ~4 ms genomsnittliga söktider (och därför kör med 12 Volt till moving-coil systemet även på 2.5" diskar) medans vanliga stordiskar och NL Enterprisediskar ligger på typiskt 12-13 ms genomsnittlig söktid.
