Vilken SSD som cache till raid?

Du säger att du har en Samsung EVO kör på den, varför inte? Det ska ju vara en Cache disk när den pajar så pajar den.

Intel Optane 900p 280 GB hade jag tänkt köpa som SLOG device till mitt kommande ZFS bygge, inte direkt billig, men då den har så ruggigt hög endurance vågar jag köra med bara en.
Gjorts lite jämförelser här : https://www.servethehome.com/exploring-best-zfs-zil-slog-ssd-intel-optane-nand/ och det ser ut som den spöar en P3700 som ju är en riktigt bra disk.

Sedan kan man ju labba med L2ARC SSDer också, men där kan man nog använda sig av något billigare då det bara är läscache som inte spelar så stor roll om den går sönder.

BTRFS har inte stöd för motsvarande ZLOG eller L2ARC. Du har inte testat ZFS på ren free/openBSD eller någon linux-dist som har ZFS i repos?

Finns det någon direkt anledning till att du byter från hårdvaruraid med bättre prestanda? Och vilken prestanda är du ute efter? Finns det någon inställning för motsvarande write through cache i Freenas? Skulle tro att en cachedisk endast kommer till nytta om du har många användare samt läser och skriver mer data än du har RAM.

840 PRO ska klara iaf 700-800 TB data innan den ens får slitna sektorer, och i ett endurance test pallade den med hela 2,4PB skriven data innan den la av. Så den klarar en hel del...

Det är dessutom MLC NAND, så du har enklare att få optimal nivå. Kan du så begränsa dens "storlek" till ca 50-75% av disken (128-192GB) som är optimalt för MLC, så dens bakgrunds algoritmer har gott om celler att flytta runt, så hålls WAf under kontroll.

Så jag skulle säga, eftersom du har en 840 PRO liggande, använd den.

Skulle du behöva en ersättare, titta på 850 PRO, då den ska också klara stora mängder skrivningar. Alt så titta på beg marknaden. Ibland finns S3700 eller Samsungs SM-diskar till salu, och de har näsan alltid enormt med liv kvar (då de är svåra att slita ut). 850 PRO har samma NAND som dessa, men sämre binnat bara. Men de klarar PB efter PB med skrivning. SM863 tex, 960GB disk har garantinivå på 6,16TB...

Jag hade dock inte satt någon TLC disk till detta jobb... så inga EVO, inga MX300/MX500, ingen Intel 545s, WD 3D SSD eller liknande. TLC kräver större OP för att jobba effektivt (66%+), samt de klarar inte av så hårt jobb. Du vill ha en MLC disk... minst.

@Esseboy MX500 är uselt alt. TLC NAND gör att du får enormt med slitage utan TRIM optimerad skrivning. NANDet klarar dessa TBW för klientbruk, inte cache bruk. Och för att kompensera kommer du från en 512GB disk bara kunna använda ca 170-200GB utrymme, annars kommer du få problem med cellrotation och dykande prestanda. Du behöver en disk utan SLC cache, som kan skriva direkt till MLC NAND för optimal livslängd och prestanda.

Ja ok, verkar rimligt. Att du inte kommer upp i några 400MB/s förvånar mig dock, det hade jag med min dåvarande rigg som var en AMD Phenom 940 (tror jag den hette) och 8GB ram, tolv diskar i Raidz2.

Ja 140MB/s är vad en modern vanlig hårddisk kan skriva sekventiellt idag så någon vajsing är det allt. Skrivhastighet generellt är tyngre än läsning, speciellt med roterande paritet, men nog ska det öka tills cpu blir flaskhalsen och inte kan göra beräkningen snabbt nog.

I mitt första inlägg här var jag inne på att du inte behöver en cache så länge du inte accessar mer eller större filer än du har ram. Visade sig att du har testat med en flera TB stor fil vilket så blev en flaskhals. Nämnde även en memory write through inställning som jag inte vet om den finns i Freenas men är en vanlig funktion i hårdvaruraid. Dock är funktionen en riktig mördare för prestanda, kan få 20-40MB/s med den aktiverad men upp mot 450-600MB utan. Värt att kolla om du har något motsvarande i Freenas alternativt i ditt raidkort om du fortfarande använder det för att koppla in diskarna

En länk
https://forums.freenas.org/index.php?threads/zfs-vs-hardware-...

Yep, är ganska säker på att det går bra
https://packet.company/blog/
Den testade disken här höll mer än 40x sin garantinivå. Samsung har medvetet satt den lågt för att inte företag ska köpa den över enterprise versionerna. Skalar man ner till din 256GB disk pratar vi ändå över 1,5PB skrivning.

Finns ingen poäng att ha en SSD och inte använda den... (säger jag som har alldeles för många på hyllan).

Cache borde kunna öka mängden prestanda på även stor mängd data, om den kan då slumpmässig IO att blir mer mot sekventiell. HDDs största problem är ju just IO prestanda, något en cache av denna typ inte borde ha så stora problem med. Med dina 140-> 30MB/s låter det som att index skrivs till en disk och blir flaskhalsen... eller så är någon skrivcache inte aktiverad (så den skriver direkt till disk, och inte till RAM), eller så gör du en typ av överföring som just kräver att den verifierar att det är skrivet till disk, typ som Write-Through.

Dock håller jag med att vill du ha prestanda är RAID 10 liknande lösning klart att föredra över RAID 5/6.
https://www.storagecraft.com/blog/raid-performance/
Här kan du läsa formlerna till RAID 5/6 och 10, så ser du varför prestandan blir sämre.
"As you can see, parity writes cause a very rapid decrease in write performance and a noticeable drop in blended performance."

Har ju utan problem 7-800MB/s med mitt kort i raid5.
Testa en vanlig dist, sätt upp raid via mdadm och kolla prestandan, är det mkt bättre så skicka freenas åt helvete

Om man skall ha en SSD för att speeda upp VM trafik över NFS är det också viktigt att kolla vad SSD:n har för prestanda när man kör små synkrona skrivningar, dom flesta konsument SSDer har inte kondensatorer för att hålla cachat data vid strömavbrott, och cachar därför inte synkrona skrivningar, vilket gör det långsamt, ibland sämre än en HDD.
Detta gör att det kan vara extremt stor skillnad mellan olika diskar i detta scenario.

Här är en (gammal) artikel ang. att välja SSD som journaldisk för Ceph, vilket också är helt synkrona skrivningar : https://www.sebastien-han.fr/blog/2014/10/10/ceph-how-to-test-if-your-ssd-is-suitable-as-a-journal-device/
Som synes är det rätt många diskar som packar ihop helt om man utsätter dom för den typen av last.

Bara till RAM. Däremot har Linux lite andra mekanismer (bcache, lvmcache och flashcache) som kan användas tillsammans med btrfs.
Vilken mekanism som är bäst och hur den ska implementeras beror på en massa saker.
flashcache och lvmcache är byggda för att hålla så hög tillgänglighet som möjligt; det kommer att vara möjligt att läsa och skriva till lagringen även om cache-enheten (SSDn, typiskt) pajar, men data som inte är skrivet till bakomliggande lager är borta.

Förutom hållbarhetssiffror på SSDn (årlig felprocent, förväntad mängd skriven data etc) kan det vara bra att kolla på hur SSDn beter sig när den fallerar. Vissa slutar helt att svara, andra skickar felmeddelanden vid läsning och skrivning medan ytterligare andra tillåter läsning men returnerar felmeddelanden vid skrivning (om det underliggande felet tillåter det, förstås).

Nej, inte om du tänker köra btrfs på en Linux. Linux har (sedan v3.9, om jag minns rätt) lvmcache, som låter dig bygga en cachad logisk volym av en långsam logisk volym och en snabb. Ovanpå den cachade logiska volymen kan du sedan bygga ett btrfs-filsystem.

Småfiler generellt är ingen bra måttstock för din prestanda då dels söktiden för att hitta filen blir längre, överföringstiden blir för kort samt skrivningen ojämn. Hitta ett par 10+ GB stora filer i nån piratbukt om du inte har några liggandes och kör dem fram och tillbaka. Testa skillnaden mellan att köra filerna sekventiellt och parallellt för att se hur prestanda anpassar sig efter olika situationer.

Async kommer höja latensen avsevärt skulle jag tro vilket är negativt för många små filer.
En annan aspekt är hur du har konfigurerat dina diskar.
Använder du ditt raidkort så måste du där ställa in sektorstorleken, exempelvis 64kb. Viktigt sedan att Freenas filsystemet också ligger på 64kb när du formaterar och partitionerar upp din Raidz, annars får du en hyfsad flaskhals även där.

100-120 MB/s skrivhastighet uppnås endast vid 100% sekventiell skrivning i början av disken, och är närmare hälften i slutet (det minskar linjärt ju närmare de innersta spåren man skriver). Värt att tänka på är också att en HDD, för allat annat än ren sekventiell åtkomst, klarar väldigt få IOPS (75-100), vilket blir väldigt tydligt vid slumpartad användning.

För FreeNAS gäller:
sync => write-through
Ger OK för skrivning först efter att data skrivits till permanent lagring, dvs inte ens din hårddisks cache används. Långsamt, speciellt om man har en HDD-pool.

async => write-back
Ger OK efter skrivning till RAM-cache. Kan teoretiskt köra i fullt blås (t.ex. enkelt maxa 40 GbE om RAM hänger med) fram tills RAM-cachen är fylld. FreeNAS försöker i regel anpassa storleken på RAM-cache:n till vad din pool klarar av. Det tar en liten stund efter uppstart, men sen kan du skriva så fort som din pool klarar av att skriva asynkront.

FreeNAS allokerar i regel 1/8 av total mängd RAM till skrivcache, och skriver ut data när denna cache är full, eller periodiskt (default max 5 sekunder). Det är antagligen därför du ser dessa toppar på 600 MB/s någon gång ibland.

Utöver detta så kommer "synkrona" skrivningar även skrivas direkt, synkront, till en ZIL. ZIL ligger per default i samma pool som du skriver till. Du skriver alltså samma data två gånger, först synkront, och sen asynkront. För att avlasta din pool, och snabba upp den första synkrona skrivningen till ZIL, är det bra med en SLOG. Inte nog med att du avlastar din pool från den synkrona skrivningen (som i sig är långsam på HDD), men du behöver heller inte längre skriva samma data två gånger.

https://www.ixsystems.com/blog/o-slog-not-slog-best-configure...

För att minska risken för korrupta VM-diskar (främst vid kraftavbrott) så bör VM-lagring vara synkron. För NFS skickar VMware per default alla skrivningar synkront, men det går att stänga av per pool om man verkligen vill. iSCSI i VMware är per default asynkront, och kör man iSCSI bör man manuellt aktivera synkron skrivning till den del av poolen som används för VM-diskar.

För övrig lagring som inte är lika kritiskt som ett filsystem i en VM kan man med gott samvete köra utan synkrona skrivningar.

Dina 9211-8i med max 8 diskar vardera bör inte vara någon flaskhals för HDDer så länge du har de i PCIe x4-slots som klarar minst PCIe 2.0 (2 GB/s) som dina kort stöder.

Vet inte vad du menar med "Async" här, men för FreeNAS är det tvärt om.

När det gäller FreeNAS så fungerar blockstorlek lite annorlunda. Deras defaultinställning är dynamisk, dvs per fil kan den i regel välja blockstorlek mellan 16-128 kB. Hur det fungerar med block-lagring (iSCSI) har jag inte koll på.

@BerraBing om du inte använder synkrona skrivningar för dina NFS-tester så kommer SLOG göra absolut nada. För synkrona skrivningar kan du få en boost, men med en Samsung 850 Pro kanske det inte blir mer än 20-80 MB/s i bästa fall. Länken som @ddelin hänvisar till pekar på ca 350 IOPS vid QD1 (och t.ex. ca 1000 IOPS vid QD3) för synkrona skrivningar till en 850 Pro, vilket motsvarar ca 5-40 MB/s (15-120 MB/s @ QD3) om IOPS bibehålls även vid 16-128 kB block.

Om du tänker använda en 850 Pro som SLOG så rekommenderar jag att du först gör en secure erase via Samsung Magician, och sen endast partitionerar upp en väldigt liten del av disken, t.ex. 8 GB. Då kommer disken själv kunna göra wear leveling extremt effektivt, och även bibehålla sin prestanda under praktiskt taget hela sin livstid.

Samsung 850 Pro är extremt tålig (över 9 PB kunde skrivas i Guru3Ds test; http://www.guru3d.com/news-story/endurance-test-of-samsung-85....

Är lite förvånad att prestandan är så låg.

Nu är detta QD4, men ändå:
https://images.anandtech.com/doci/8216/850%20Pro%20256GB%20ATTO%20write_575px.png
Vi pratar lätt 30k IOPs.

Tittar vi på en mixed transfer, också QD4 har vi ändå runt 175-ish MB/s random på 512GB storlek:
http://images.anandtech.com/doci/12348/rm-s-850pro-512.png

Och tittar vi just test med sekventiella skrivningar så är värdet ännu högre redan vid QD1:
http://images.anandtech.com/doci/12348/sm-s-850pro-512.png

Så hur i tusan kan de få så dålig prestanda?

Ärligt så räcker <50% nivån kanon. MLC + OP + dens aggresiva GC gör att den håller bra WAf i den sitsen.

Finns ett test till som gjort med hård slitage till döden på denna disk. Fördelen med detta är att de gjorde test med retention test efter 2PB och även räknade lite på WAf både vid 50% och 85% och vid båda fallen pratar vi under 1.05x. Mao... saaatans bra.

Så har han 100GB / 256GB disk, räcker det mer än väl för att den disken ska ha perfekt optimalt förhållande. Interna NANDet är betydligt snabbare än SATA gränsnsittet, så det är inga problem för den att hinna rensa i bakgrunden.

Det var inte Guru3D som gjorde detta, utan tyska heise.de.
De testade en hel del SSDer samtidigt fakiskt och fann att många SSDer nådde fantastiska mål. 750 EVO tex på ca 1.2PB... inte illa för 2D TLC NAND. Enda problemet med deras tester är att jag vet inte om det var konstant skrivning, eller pauser. För lite retention tester och annat gör faktiskt mycket. SSDer kan ofta skriva mycket data innan de dör, men de kan dö lång före det om strömmen tas ut.

https://www.heise.de/newsticker/meldung/SSD-Langzeittest-been...
https://www.heise.de/newsticker/meldung/SSDs-im-Stresstest-mi...
(Tyska om du kan, eller så får du översätta)
Hela artikeln i sig är dock bakom en betalvägg.

Synkron skrivning är långt ifrån lika snabbt som den asynkrona skrivningen i dessa tester. Jag kan tänka mig at dessa SSDer inte nyttjar sin DRAM-cache (då dessa konsument-SSD:er saknar power loss protection) när man ber de skriva synkront.

Bättre att partitionera så lite som möjligt och nödvändigt när man inte har stöd för TRIM. Ju mer "spare" via over provisioning desto bättre wear leveling. Storleken för partitionen på en SLOG behöver i regel inte vara mer än dubbelt så stor som skriv-cache i RAM (FreeNAS default är 1/8 av RAM) eller så mycket som din pool hinner med att skriva på säg 10 sekunder.