WD har en tendens att nerfa sina diskar i externa drive på olika sätt (tex 3.3V lina i white label) och är det inte fysiskt så kan det vara saker i firmware som gör att prestandan inte är optimalt i just tänkt NAS-användande eftersom det är just att folk som shuckar billigare externa diskar för att fylla NAS som de med dessa 'sabotage' vill mitigera. det här 'kriget' har pågått sedan WD-green tiden...
Seagate verkar idag skita i sådant och diskarna inne i dessa externa diskar är samma kvalitet och firmware som motsvarande lösa diskar...
Toshibas diskar och motsvarande deras externa diskar har jag ingen koll på - men har heller inte hört att de skulle vara nerfade i versionerna i sina externa USB-diskar.
WD:s 2.5" diskar så finns ofta ingen SATA-anslutning alls utan USB/SATA-konvertern sitter på diskkontrollerkortet samt krypteringsmotorn sitter också i själva USB/SATAgränssnittet.
Skulle jag bestycka en NAS med diskar från externa USB-diskar så skulle jag nog välja annat än just WD av ovanstående skäl...
---
En ytterligare sak att tänka på om du skall använda BTRFS som filsystem (som de flesta köpeNAS som klarar > 16 TB i filsystemstorlek använder idag) är att du vill ha mycket RAM på disken - minst 128 MByte, helst 256 MByte på själva drivern. BTRFS har många roliga feature - men den gillar _inte_ diskar med små mängder med RAM på sin diskkontrollerkort och det kan bli periodvis _väldigt_ trötta när filsystemet skicka på datasets (eller om det är metadata?) som diskdrivern inte själv har plats att sortera skrivordningen på i sin egen RAM för att den är för litet innan det skall skrivas ned på disk... BTRFS/linux verka använda NCQ rätt mycket och är scopet större än vad RAM kan rymma/fylla ett spår komplett så blir det segt och det ser då ut att göra en skrivning av 4k-sektor/block per diskvarv istället för att skriva kontinuerligt efter varandra... - typ att skrivordningen LBA-mässigt är 10, 9, 8,7 och 6 istället och måste vänta ett helt skiv-varv efter att LBA 10 skrivits innan sektorn LBA 9 före kan skrivas, istället för att sorteras som 6,7,8,9,10 först och sedan kan skrivas efter varandra i rad i ett enda svep.
Det skiljer också mellan diskar då en WD green 2TB med 32 MB ram är ungefär hälften så snabb som motsvarande Seagate 2TB också med 32 MB RAM (2010-års diskar) och de interna strategierna i diskarna verkar vara olika och ingen av dem är ens i närheten lika snabb som en disk med 256 MB RAM där man inte ens märker någon fördröjning/stall när det uppdateras. Detta kan man se med 'atop' medans man skriver och läser tex. backupper under linux mot BTRFS-system på externa diskar. Varför och hur det gör så är inte utrett - har heller inte kört på 18.04 Ubuntu för att se om det är något fixat och kanske är en bugg i botten - och kör man diskar med ordentligt med RAM på diskdrivern så är det ett icke problem, men dock något man bör ha i bakhuvudet att problemet existerar om man stirrar på en tänkt RAID-lösning baserat på en rad WD-black 2.5" disk med bara 32 MB intern RAM...
Detta en praktisk observation när jag har kört backupper mot gamla diskar i diskdockor med BTRFS filsystem [1] och disk på 2-4 TB med 32 resp 64 MB RAM (gamla WD-diskar) men inte över huvud taget sett problemet när man kört mot Seagates archivediskar (som har 256 MB RAM) - förvisso sett det mest när disken skrivs med dubbel uppsättning metadata (dvs. redundant metadata ifall den ena uppsättningen skulle gå korrupt av någon orsak - har dock aldrig sett sådant felläge skett hittills - och kan lätt omvandlas till RAID 1 om man kopplar in en disk till för större storlek på sin backup)
[1] Användningen av BTRFS som filsystem på backupdiskar är för att den verkar (efter mycket egna prov) vara idiotsäker och utan risk för filsystem-haveri även vid glappande sladdar och plötsligt avstängda diskar mitt under full skrivning - till skillnad från NTFS... till detta är BTRFS bra på shinglande diskar eftersom den skriver framåt hela tiden och inte återvände och modifierar redan nyss skriven data, detta på atomär nivå och gäller även för metadata - sedan är det här med snapshot lockande när man kan ha kvar äldre versioner av backupper och ändå uppdatera sina backupper i önskad antal generationer innan sin rsync och fungerar mycket bra och är förlåtande om man snubblar med en missad '/' på patharna för rync och den börja radera en massa filer - '--delete' i rsync kan vara väldigt destruktiv ibland..., och när det händer och inser att backuppen är sönderskriven så gör man en snapshot på den nyss tagna snapshot och kan försöka igen på orörd backup som den var precis innan den misslyckade körningen - den tryggheten är värd mycket, att just kunna backa och göra om när det inte gick som tänkt.
Och en snapshot med stor dinglande filträd i sig går fort att ta bort och det finns ingen ångervecka där när man gör den - är det borta så är det borta och går på sekunden när man kör kommandot. - detta till skillnad när man med rm -r skall tömma en filträd på kanske miljoner filer och tar sin goda stund på sig...
---
Köper man lösa NAS-diskar så har enligt Blackblaze Seagates stora diskar >6TB klarats sig väldigt bra och är helt klart snäppet högre än generationerna kring 4-6 TB diskar (Seagate har en modellserie i 3TB som är ökänt dålig och dragit ned hela Seagate rent ryktesmässigt, men undviker man just den serien så är det på samma nivå som andra disktillverkar och i vissa fall tom. bättre och i nivå med HGST när det gäller storvolym-diskar 8TB och större)
Seagate brukar inte fippla med diskarna som stoppas i externa disklådor - dock kan innehållet variera med tiden - länge var deras 8TB externa USB-diskar av just 8TB archive-diskar och man visste att man fick just sådana när man köpte diskarna och de var identiska med motsvarande lösa 8TB-diska diskar utan någon fuffens. Även om folk har varit skeptiska till dem i början (och somliga använde dessa till fel saker) så har dessa visat sig vara mycket driftsäkra och också fungerat bättre än väntat i tex. NAS-sammanghang för tex. lagring av mediafiler med väldigt liten förbättringspotential om man skulle ha bytt dessa till riktiga NAS-diskar.
På den tiden var det väldigt stor skillnad på de som ansåg att diskarna var dåliga utifrån specifikationerna och inte provat själva och de som faktiskt hade provat diskarna i olika raid-konstellationerna och konstaterat att dess 'draw-back' var inte så stora som det ryktades om och i de flesta fallen var mer än godkänt användbara - och krasst sett - disken var egentligen inte tillverkad med sikte mot konsumenter utan tänkt mot just datacenter av just anledningen att det var en shinglad disk och därmed ansågs att dess draw-back vid skrivning kunde hanteras bättre där.
läsmässigt har de inte haft några uppenbara nackdelar än andra diskar och vid tiden när de kom så var de förbaskat snabba i både söktid och kontinuerligt skrivning/läsning - med skrivning och fel skrivmönster kunde man dock hamna i inte så bra prestanda (och NTFS hade en skrivmönster som gjorde att man snabbt kunde hamna i det läget om man tex kopierade en filsystemdisk med massor av små filer - medans andra filsystem som ext4 så kunde man skriva 10 ggr mer innan man ramlade i långsamhetshålet och med BTRFS i princip aldrig nådde den gränsen hur mycket man än skrev.)
med andra ord - dom prestandanedsättningarna med shinglade diskar som alla ylade om och av orsaken ansågs dissa - har väldigt mycket med använda filsystem när och om man når begränsningen eller inte och NTFS råkade vara en av de allra sämsta av alternativen där man fort hamnade i hålet (förvisso först efter runt 30 GB skrivet)...
resonemangen ovan gäller förvisso för en idag sett rätt gammal modell av disk - men detta resonemang gäller fortfarande än idag för alla shinglade diskar och top notch största modeller av diskarna som lanseras idag är alltid shinglade diskar medans PMR/GMR-diskar i samma storlek släpar alltid efter med något eller några år då det är skrivningen av datat i tillräckliga smala spår som är problemet - inte att läsa smala spår.
---
Det här med diskar som är initialt snabba men plötsligt blir långsammare efter en viss skrivmängd vid kontinuerlig skrivning och behöver vilotid innan de blir snabba igen, ser man numera också SSD med QLC-celler och märks framförallt när diskarna börja vara mer än 75% fyllda (fanns även på SSD med TLC-celler men inte lika utmärkande vägg när man körde huvudet i det) så denna beteende med snabbt en stund och sedan jättelångsamt vidare om man inte ger vilotid kommer allt mer även på icke snurrdiskar och inte bara på shinglade snurrdiskar vid läge slumpmässiga skrivmönster med små block/filer eller återkommande backskrivning i enstaka sektorer på sektorer som redan nyligen skrivits, som konstant uppdaterande metadata i filsystem (NTFS dilemma på shinglade diskar)