High-end NAS från de större NAS-tillverkarna och en riktig Fil-server möts någonstans på vägen i prestanda.
En riktig server är byggd med fokus på driftsäkerhet och bra dataskydd.
Driftsäkerhet betyder underklockad proppar av servertyp, ECC-minne på allt (även på eventuella cache-RAM på diskkontrollerkort/HBA, batteri/konding/flash-backup av RAM på diskkontrollerkort och dito också på SSD som används), redundans på fläktar och ofta har man minst fyra nätverks-uttag utöver den man sköter servern med, och inte sällan en eller flera 10GBit-länkar.
Man använder SAS-HBA och även SAS-diskar om möjligt, även om SATA-diskar fortfarande går att använda som budget och man tullar på dataskyddet, dubbla nätaggregat där man kan byta en i taget under drift helst.
Vad är syftet men en riktig server - jo tillgänglighet och att datat inte förvanskas av hårdvarumässiga orsaker och att man aldrig behöver besöka servern fysiskt efter installation på minst 5 års drifttid (gäller dock bara med Enterprise SAS-diskar med AFR 0.1-0.2, near line Enterpise-diskar ligger från 0.7 - 1.5 i AFR då de i grunden är SATA-disk chassier med en SAS-kontrollerkort och sannolikhet större att 1 disk behöver bytas på 5 år i en 8-disk-tråg)
Om man pratar om datasäkerhet/risk för datacorruption så ger SATA över sin länk en felsannolikhet på 1.4 oupptäckta fel/år vid 500 MB/s under ett år dvs. 1 fel per 1*10^17 bit när man har en störningspåtryck av BER på 1*10^-12 på länken (SATA-sladden)
(BER 1*10^-12 är ett standardvärde för datalänkar med låg bitfelssannolikhet som databussar, ethernet, fiber etc. medans bitfelstakt från media (magnet och optisk samt multilevels flashminne och Radio-vior (som Wlan) innan rättning brukar sättas 1*10^-4 och ibland ned till 1*10^-3...)
Datasäkerhet på själva hårddisken ligger på ca 1 bit fel per 1*10^20 (konsument-SATA) - 1*10^24 (Enterprise-SAS) bit för oupptäckta fel (uppskattade värden då det inte skrivs ut av HD-tillverkarna, men brukar vara minst 1 miljon ggr lägre sannolikhet än angiven värde för ej rättningsbara läsfel). I det här fallet är det länken (SATA-kabeln/SATA-bakplanet) mellan hårddisken och kontrollerkortet/datorn som är den vekaste delen i kedjan.
SAS-länkarna utan extra skydd startar med max 1 fel per 1*10^21-bit överfört vilket innebär max 1 fel per dryga 7000 år vid 500 MB/s året om, eller 1 fel per år vid en serverfarm på 7000 SAS-länkar/SAS-diskar och SAS kan med utökade sektorer med checksummor nå max 1 fel per 1*10^28 Bit överfört.
För NAS med 1-2 st SATA-diskar och även 4-5 diskar med okritisk data så är detta inte ett problem i konsumentsammanhang, men börja det vara mer än 4-6 diskar på tungt lastad företags-NAS så börja sannolikheten för oupptäckta transmissionsfel bli besvärande då det kan vara 6 - 8 datafel som gått under radarn på ett år - och ännu mer om man har SATA-expandrar med än fler diskar mm. då varje länk räknas och adderar sannolikheten för fel.
RAID säger någon - ja de upptäcker en del av felen men inte alla då tex. paritet bara detektera udda antal bitfel samtidigt medans jämna går förbi, checksummor fletcher (används i ZFS) är också rätt glesa med hammingavstånd max 3 bitar fel (och mycket är bara på Hd=2 då den är känslig i fördelningen mellan '1' och '0' och hur många som är efter varandra i sekvens) samtidigt medans en CRC-summa startar på 4 (SATA) och upp till 6 (SAS) bit fel samtidigt för 100% garanterad upptäckt, men det beror på längden av meddelandet som checksumman täcker och använda CRC-polynom...
SATA använder IEEE 802.3 CRC och har HD=6 (HD = Hamming-distance - dvs. max antal bitar fel samtidigt i datablocket för 100% upptäckförmåga) vid 33 Byte och är nere på HD=4 för en 512-bytes sektor (den paketstorleken SATA använder sig av och är fixerad) medans SAS använder sig av CRC32-C och ger bibehållen HD=6 till 655 Byte (dvs. rymmer en hel 512-bytes sektor med bibehållen 100% 6-bitfels upptäcktsförmåga och kan överföra upp till 256 MiByte vid HD=4 medans SATA bara klarar upp till 11 kiByte vid HD=4 )
- det är det som är skillnaden varför SAS har ca 10000 ggr bättre upptäcksförmågan av bitfel än SATA och det beror 'bara' på en polynoms värde i skillnad medans logiken som räknar på det är samma (IEEE 802.3 CRC32 = 0x82608EDB, CRC32-C = 0x8F6E37A0 i polynom)
Noterbart BTRFS använder CRC32-C som checksumma för sina sektorer (ext4 gör det också för sin metadata) vilket gör att det är ca 10000 ggr bättre 'upptäckförmåga' av fel än använda CRC32 i SATA-länken, medans ZFS använder Fletcher checksumma vilket har ca 1000-10000 ggr lägre 'upptäckförmåga' av bitfel än den CRC32 som används i SATA-bussen och därmed sannolikhetsmässigt kommer missa många av dom oupptäckta felen som SATA-bussens CRC32 släpper igenom...) - ZFS kan förvisso byta sin checksumma till en SHA256 och stärka upp rejält (vilket görs automatisk när man slår på automatisk deduplicering) men de flesta brukar ångra det och vill backa igen (och upptäcker att det inte går) då systemet tappar mycket prestanda.
Med andra ord kompromissar där man i ZFS kan välja mellan en rätt dålig checksummekontroll och en mycket bra (snabbhet men slarvigt vs. långsam men noggrann), medans BTRFS kan man än så länge inte välja utan sitter med en medelbra feldetektion med idag samma beräkningsprestanda som Fletcher med hjälp av HW-stöd för CRC i våra CPU:er, men så var det inte när man började designa och utveckla ZFS, därav valet av Fletcher...)
Man kan säga att steget mellan konsumentprylar och semi-Pro och riktiga PRO-prylar har en skiljelinje som går vid SATA/SAS. och idag är near-line SAS-diskar från 8TB och större bara hundralappar ifrån vad SATA-diskar av samma modellserie kostar och enklare LSI-baserade SAS-HBA runt tusingen, så bygger man en mer seriös server där datasäkerhet är viktigt så använder man inte SATA-diskar - punkt.
Och det gäller också när man tittar efter NAS/server i den högre prislappen, kan den inte ta SAS-diskar så är det inte PRO-nivå oavsett hur snygg fronten är.