svarar bara på några av posterna
Skrivet av sniglom:
Kommer köpa likadana diskar.
@xxargs
Stort tack för utförligt inlägg.
Bara så jag inte missförstår dig, diskcache = ram på drivern?
Eller menar du "vanligt" ram i systemet som upplåts till btrfs? Jag kommer inte köra något häftigt kontrollerkort.
Det är mängden RAM på själva diskdrivern som är det viktiga - när 'problemet' spelar in så har RAM på datorn inte någon betydelse längre och är för sent när det flushas mot disken - det handlar om skrivordning av sektorerna och det är bara disken själva som vet vilken ordning som ger bäst flöde mot skivorna och BTRFS (med DUP) så verkar mängden som skickas iväg på en gång vara större än 80-90 MB i klump och en disk med RAM-cache på 128 MB och mindre så blir det inte bra alls då 'scoopet' från host är större än sorteringsutrymmet i diskens RAM (och NCQ-hanteringen i SATA-diskar har ofta mycket övrigt att önska, särskilt på äldre diskar ) och en gammal disk (WD-green) med bara 16 och 32 MB RAM var en riktig pina då det vara stall på över en minut när inget händer då det känns som att sektorerna skrivs i baklängesordning och typ 1 sektor/4k-block per varv och det är 23000 sektorer i skrivkön mot disken som just flushades från linux disk-cache... (kan ses i bl.a 'atop -fF 1', som root helst då)
Observera - detta var inget jag märkte alls på när diskdriverna var på 256 MB RAM (8TB seagate archivediskar) med fick se (tidsmässigt katastrofala) verkan av det när man försökte med gamla 2TB WD-green diskar med 16 och 32 MB driver-ram som andra backup..
På HW-RAID-kort med modell större mängd RAM-cache (> 512 MB) så görs den här sorteringen och skrivordningsoptimeringen av LSI-kretsen så att det skall bli så bra skrivordning som möjligt mot diskarna även om sektorerna kommer i baklängesordning från host beroende vilken RAID-typ som används, men sådan strategi existerar inte alls på en enklare HBA som IBM M1015 mfl. varianter på samma LSI-chip utan allt hänger på hur diskarna själva hanterar det och om man är modig att slå på diskarnas skriv-cache och inte bara läs-cache... (UPS rekommenderas om man har skrivcache påslagen på diskdrive och inte har en HW-RAID med egen RAM och BBWC) - att skrivcachen är påslagen gör _mycket_ på skrivprestandan
Sådant med BTRFS lite oönskade beteende på skrivordning och storlek i skrivningen när den flushar sin metadata går förmodligen att tweeka i linux-kärnan, men nu pratar vi om stock-installationer av våra vanligaste stora linuxdistributioner där det inte förväntas att någon pillar på en massa parametrar under /proc för att få det användbart...
Detta är något som kanske borde återmatas till de som hackar linux-kernel men eftersom det knappt skrivs alls om det så verkar det inte vara ett stort problem - förmodligen för att man använder stora diskar idag med mycket driver-RAM på dessa.
Citat:
Vad gäller Toshibas P300 har jag inte kunnat hitta någon info alls om hur många skivor den har.
Men tror du att 128MB cache kan bli ett problem, bör den undvikas därför oavsett.
Alla diskar med 128 MB RAM och mindre bör undvikas om man skall köra BTRFS som filsystem om du frågar mig, och Toshiba P300 är motsvarande Seagates Barracuda och WD-blue - för användning som enkeldisk eller tillsammans med en SSD för OS i en stationär dator.
Skall man ha multi-diskar i samma chassier skall man åtminstone titta på NAS-klassade diskar (dvs N300 för Toshiba) då de generellt har högre vibrationstålighet och försöker inte läsa dåliga sektorer mer än ca 7 sekunder och sedan säger IO-error medans en desktopdisk kan vara borta i minut och mer vid läsfel och disken blir då utkickad ur RAID istället för att automatiskt skriva om den dåliga sektorn - det är en standard inom RAID att inte vänta mer än max 8 sekunder på en disk i svarstid innan den kickas ut då väntandet sölar ned RAID:ens prestanda medans processen pågår
Nu börja Toshiba och säkert de andra också med driverbaserad skriv-cache som inte förloras vid strömavbrott som klassiska snurrdiskar gör normalt [1] och med icke transaktionsbaserade filsystem som NTFS, olika VM-filsystem etc. med katastrofal verkan medans BTRFS/ZFS med transaktionsbaserad filsystem har betydligt bättre recovery och rollback-funktion om en skrivning inte slutfördes korrekt och också förmåga att upptäcka fel på det sista som skrevs med mha. checksummor eftersom skrivordningen kan vara helt annorlunda mot disken än det som host nyss sände iväg...
[1]
Och även fel hos SSD ibland, då konsumentversioner av SSD har inte buffertkondingar som kan ge energi nog för att slutföra lagringen och tömma RAM-skrivcache (som kan vara rätt stor i en SSD/NVMe) om man får avbrott mitt i skrivningen - på SSD resulterat det när timingen, en dålig dag, i stendöd SSD - dvs. blixt från klar-himmel haveri och allt borta utan en chans till räddning...
Förmodligen löser Toshiba det med antingen flash eller att det hinner skriva till skivan på dedikerad plats innan varvtalet gått ned så mycket då snurrdiskar har sedan länge använt spindelmotorn som generator för huvudparkering etc. vid plötslig strömförlust och att skriva 256 MB från skrivchache till disk handlar om 1 sekund och då hinner det inte varva ned speciellt mycket med skivpack på 4-6 skivor som svänghjul innan den själv avsiktligt bromsar ned skivornas rotation
Citat:
ST6000DM003 är faktiskt specad till 1*10^-15, (P300 till 1*10^-14) men har det värdet en relevans i verkligheten, jämfört med exempelvis MBTF? När jag försökt läsa om det online verkar det mest vara "något som tillverkaren drar till med".
Mest för att belysa att WD-red är en skräpdisk med oförtjänt god förtroende och fanboy-grupp som slår ned på allt och alla som har annan åsikt, när man inte ens är rädd om privatkonsumenternas data med anständig felhantering och ökad risk för oupptäckta fel i dataflödet....
Ingen som håller på med server skulle stoppa in en disk med bara 1*10-14 i ej rättningsbara fel (dvs. IO-fel som inte kan läsas korrekt ens med flera omläsningar)
Riktiga serverdiskar av Enterprise-modell har 1*10-16 i ej rättningsbara fel - men där har man typ >20% extra redundans med extra reed-solomokoder, tål multipla sektorbortfall, dualport SAS etc. där en SATA-disk på normalt 450 GB, är bantad till 300 GB på en SAS-Enterprisedisk pga. all extra paritet tar så mycket extra plats för samma storleksklass.
- men så är AFR nere på 0.1-0.3%/år trots att det är 10 och 15 krpm-diskar i jämförelse med SATA-diskars 1-2% AFR
Citat:
Men för en raid5-setup i btrfs blir det något mindre data att köra på 3 diskar.
Säkerhet är inte superkritiskt, snarare på nivån jag föredrar att inte tappa all data om en disk dör.
Viktig data placerar jag redundant och offline redan.
Ska jag köra på 8TB och undvika Barracudan samt hålla mig under 7200rpm (för ljudnivå) är det enda ekonomiskt rimliga alternativet WD Red.
Hur och hur mycket de låter beror på generation diskar - man kan inte säga att bara för en WD-black på 7200 RPM låter och morrar och får hela diskdockan att brumma högljutt (har en sådan...) - att det innebär att alla andra diskar på 7200 RPM gör likadant.
Moderna diskar på 8TB och högre skulle jag säga är rätt välbalanserade av antagligen skälet att de måste vara det pga. packningstätheten... det som dock kan skilja sig är att 7200 RPM-diskar har en smula mer sus och att armrörelserna är mer tydliga och mer 'knackiga' i ljudet av just anledningen att de också söker betydligt snabbare än en WD-red.
Jag har själv dålig erfarenhet av WD-RED (precis som andra har det med Seagate) så jag kan inte säga med hjärtat att de är bra - trots allt är de ommålade WD-green diskar i grunden (den som ställt en WD-green och en WD-RED bredvid varandra när WD-RED var precis nytt - förstår poängen, det var bara färgen på etiketten och firmwaren som skiljde sig)...
Och jag tycker bättre att man fokuserar på diskar som är från 8TB och uppåt - generationen då det är helt andra diskar än de som byggde på 1TB-platters (läs 4 och 6TB -diskar och 5400 RPM ) då med 8TB diskar har man helt enkelt tvingats till att bygga bättre diskar med datacenterkvalitet och sedan har kvalitetshöjningen stänkt över mot konsument-versioner och inte som tidigare generationer på 2, 4 och 6TB-diska med 1TB-platters och avsiktligt byggda som just konsument-diskar, lägre varvtal och med lägre ambition (som 1*10^-14 i ej rättningsbara fel) och max last av 55 TB läst/skrivet per år... tittar man på blackblazers statistik så har generationen med 8TB och uppåt i princip halverar AFR gentemot tidigare generations diskar på 4 och 6 TB och de nyare 8 och 10TB är riktigt bra, i stort sett på HGST-klass oavsett märke (Seagates 12TB diskar skall man dock undvika då de helt klart har ett problem som ökar över tiden)
Man kan också ganska krasst sammanfatta att alla diskar som ligger på 5400 och 5900 RPM är gamla generationens diskar (undantag Segates 8TB Archivediskar som låg på 5900 RPM och var den första av den nya generationens diskar och egentligen inte alls tänkt för konsument övh. utan just för datacenter) och det är i stort sett ingen ny diskmodell idag som designas för annat än 7200 RPM (sedan att det kan komma ut nerfade 7200 rpm-diskar till 5400/5900 RPM i form av 'white label' i olika externa USB-diskar från WD är en annan sak - men designen är fortfarande inte för dessa lägre varvtal utan just 7200 RPM i grunden)
WD-RED är en NAS-disk medans Seagate Barracuda är en desktop-disk - skall det användas i NAS-bruk/multidisk i samma chassie så bör du ha just NAS-diskar och skall de ha 256 MB i RAM på drivern (vilket jag anser är nödvändigt om man kör BTRFS och inte gillar stallningar) så är det 8TB och större som gäller - oavsett om det är PMR eller SMR-diskar.