Vilken SSD som cache till raid?

Aah.. bra poäng.
Är ju bara de som har kondensatorer som verkligen gör denna nivån.

Som sagt, disken klarar av det. Finns ingen poäng ur diskens synpunkt att göra göra så stor OP, när 50% garanterar att där är låg WAf och garanterat lediga celler. Det är ju därför jag länkade dig dessa tester som visar att även i extrema situationer, klarar den av detta.

På sämre SSDer, kan jag dock hålla med. Men då kommer ju nästan frågan om det verkligen är lönt att ens offra en 850 PRO för detta jobb, om du ändå ska ta till marginaler som hade gjort sämre TLC (850 EVO) diskar möjliga till det med 8GB/250GB.

Sen om du inte behöver mer... okej, då förstår jag poängen. Men sätt den största storleken du kan behöva, för den disken har inga problem med det.

Ja, "async" om det inte är extra kritiskt med dataintegriteten om det t.ex. skulle bli strömavbrott eller liknande. Om din överföring mellan VMar är synkron eller ej kan jag inte svara på. Testa att tvinga "sync"-läget för din datastore till på och av, och jämför.

50% partitionering räcker långt, men om du vill ha en SSD till endast SLOG finns det ingen anledning att skapa en så stor partition för just det. 8 GB räcker gott och väl. Ta i med 16 GB om du verkligen måste. Jag tänker att enhetens firmware, efter en secure erase, vet om hur mycket som inte är partitionerat, och kan använda detta för wear leveling. Om man har en partition på 50% så kommer i värsta fall 45% av cellerna förbli helt oanvända. Beror nog på hur data skrivs för en SLOG, och de detaljerna har jag inte koll på.

Stäng av "atime" om du inte behöver veta när filer senast lästes. Det tar bort ytterligare lite onödig overhead, speciellt när man jobbar mot många väldigt små filer.

Jag har i dagarna satt upp en ny server. Jag är duktig på Windows och och kunde inte ett skvatt om Linux men ville lära mig detta. Har tidigare kört hyper-v och storage spaces som fungerat utmärkt men ny kunskap är aldrig fel.

Severn kör nu Proxmox VE som hypervisor med ZFS på hosten.
Jag har filserver (samba) samt plex i 2 LXC containers.

Jag har 6st WD Red 4TB diskar som körs i Raidz2, dvs liknande raid 6.
Vid kopiering av filer från server till min windows 10 klient ligger jag på runt 600-600 mb / sec. Kopiering till server ligger på runt 300 - 400 mb/sec.

Jag kör alla diskar via de inbyggda sata-kontakterna på moderkortet.

Jag har 10GB Ethernet hela vägen.

Min poäng är att dina hastigheter verkar låga.
Jag är inte ens säker på att mina egna hastigheter är helt optimerade.

Håller fortfarande på att lära mig.

@BerraBing: "Servern" är bestyckad med:
1st Intel Xeon E3-1245v5 CPU
64 GB Crucual DDR 4 ram (icke ECC, datorn har varit en workstation tidigare)
Asus P10S WS moderkort
6x 4TB WD Red
1x Kingston KC400 256gb ssd, bootdisk.
Intel X540T2 10Gb Ethernet

Jag har satt upp ZFS på själva proxmox hosten då det finns native stöd för detta.
Filservern (samba) körs som en Container ovanpå Proxmox, där jag i Proxmox mountat ett antal olika datastores från hostens ZFS till till mina containers.

Har en ZFS pool med alla 6 diskarna tillagda, ingen cache.

Samtliga datastores i denna pool har LZ4 compression och 1mb block size.
Det bör dock tilläggas att jag ändrade från standard block size till 1mb efter jag flyttat in allt data, så detta gäller bara det som jag lägger till nu i efterhand.
Ökade från 128kb till 1Mb då större delen av filerna är filmer och musik som jag rippat från sånt jag köpt genom åren.

Kommer skapa en ny datastore med mindre block size om jag ska köra databas på någon av dem

Samtliga tester jag gjort med kopieringar hit och dit är med mkv-filer runt 15-31 Gb i storlek som kommer från mina blu-ray filmer som nu förpassats till vinden. Har även testat med en 31Gb stor .tar fil.

Jag är ingen expert på detta utan nybörjare. Men som du ser är det ganska enkel hårdvara med mycket standard. Värt att tänka på är att alla mina tester gjorts mellan maskiner som faktiskt inte sitter i samma host, utan via ett 10GBE nätverk.

I ditt fall tolkar jag det som att du skyfflar data "mellan" maskiner som sitter i samma host och som jobbar mot samma underliggande datastore.

Skulle detta inte kunna innebära att du gör en Read/Write på samma diskar, och detta har väl en lägre prestanda än en read respektive write från olika datakällor?

Här för någon som har mer erfarenhet av storage gärna tillrättavisa om jag är ute och cyklar.

Just jämnare prestanda är ju en fördel, men det låter ändå som låga siffror för sekventiell prestanda tycker jag. Du borde få 2x diskarnas prestanda i skrivning med 4 diskar.

Att småfiler gick snabbare är är dock något positivt.
Ofta är ju nätverket (Gbit) flaskhalsen ändå, förutom med småfiler, så får man dessa upp till den nivån märks det.

DOH!
Murphy got u again

Får hoppas den skalar bättre, för något är konstigt.

Har inte läst tråden, bara TS inlägg.

Jag kör själv med FreeNAS (ZFS) som lagring över NFS till en VMware ESXi host. Med Raid10 + en Intel 540 (rekommenderad av FreeNAS på IRC) så fick jag ut ynka 60-70 MB/s i write. Bytte upp mig till en DC3710 och får nu ut magiska 350 MB/s.

Nuff said.

Det stämmer ZFS poolen ligger direkt på hosten och delas ut som shares via nätverket (från en container som har delar av poolen mountad).

Intel 520 skulle kunna fungera, men jag vet inte med hur bra prestsanda. 240GB är den bäst presterande 520 versionen, men 180GB ska vara rätt nära. 120GB har färre NAND paket och därför har sämre skrivprestanda. NANDet de använder är också på 5k P/E och MLC så det bör hålla rätt bra. https://www.intel.com/content/dam/support/us/en/documents/ssd... (Se sid 7 för okomprimerbar prestanda)

Intel 530 hade jag nog inte kört dock, eftersom den är senare generation och har därför större NAND mängd / paket, vilket gör samma storlek långsammare. (520 har 8, 530 har 4) 530 har också en bugg med sin energisparläge, som kan ge rätt enorma WAf och sliter ut NAND även när disken inte används. De har även "bara" 3k P/E NAND så lite sämre tålighet. (Du kan se min disk på jobb här och dens enorma WAf, trots att den knappt används) https://www.intel.com/content/dam/www/public/us/en/documents/... (Se sid 8 för okomprimerbar prestanda, notera hur låg sekventiella prestandan är)

Men jag kan förstå varför 520 tex kan vara snabbare än 850, då moderna SSDer är hårt designade att använda DRAM cache. Men utan kondensatorer så kan de tappa data som inte hunnits skrivas till NAND. Och om jag förstått det rätt är det här problemet är med denna typ av last du har... den kan inte använda denna Cachen, varpå prestandan dyker på SSDerna. Detta är ju varför enterprise klassade diskar med backup kondensatorer kan fungera bra här, medan konsumentdiskar får så dålig prestanda.

Sandforce kontrollern som både 520 och 530 bygger på är dock DRAM lösa. Denna kontroller skriver istället direkt till NANDet, och har endast en ytterst liten mängd RAM internt, så den synkrona prestanda bör blir rätt bra. Så även om den har lägre prestanda rent... benchmark-mässigt, så kan den mycket väl ha bättre prestanda i detta special scenario. De har även komprimering som kan hjälpa till med viss typ av data. Så jag hade definitivt testat 520 180GB disken... och med 8-16GB storlek lär du inte ha problem med WAf med den gamla kontrollern.

Kom på en sak, vad kör du för nätverkskort på dina VMs? Kör du med VMXNET3?

520, ja, den borde kunna fungera bra, kanske inte enterprise nivå, men för konsument SATA iaf (finns även liknande i listan som ddelin linkade tidigare, där tom 60GB disk får rätt bra prestanda)
530 lär inte klara det i längden / sämre prestanda.

Varför så liten partition, är för Write Amplification factor på denna kontroller är inte så pass bra utan TRIM. Du kan säkert ta till med 1/4 av diskens storlek (ca 32GB på 120GB disken), men jag hade nog inte gått över det, då den enda bit som Sandforce kontrollern har för att få bra WAf är TRIM + komprimeringen, och ingen av dessa kan du lita på med en cache med denna typ av jobb.

Du vill ju att den ska hålla så bra som möjligt, och skriver du stora mängder data så kommer ju den cachen att skrivas om, och om igen relativt fort och kontrollern bör då ha 1 uppsättning data (nuvarande), 1 uppsättning data (nytt inkommande), 1 uppsättning data (gammalt som inte hunnits tömmas) + marginaler på detta så jämnt slitage kan ske.

850 PRO visste jag pga tester kunde hantera det pga hur kontrollern är gjord (där en kärna bara gör GC mer eller mindre, samt NANDet är mycket snabbare än SATA, så den hinner städa. Tyvärr verkar dens prestanda rätt dålig här, även om den tål det, så jag hade nog kört på 520 disken.

Se dock till att du uppgraderar deras FW först om det inte är gjort, då Sandforce kontrollern hade en bugg förr i tiden (som är lagad). Tror Intels diskar var immuna mot det, men de har släppt ny FW ändå.

Det är skillnad på SLOG och SLOG, uppenbarligen. Allt handlar väl i slutändan var du vill dra gränsen. Jag menar om vi använder säkerhet som liknelse; hög säkerhet är bra, men inte så hög att det inte går att använda. På samma sätt är hög hastighet bra, men inte till vilket pris som helst, och i detta fallet så handlar det ju om vad du vill få ut och vad du är beredd att ge. Jag kom över mina diskar billigt här på Sweclockers, jag hade tur.

De tester jag gjort är på en Windows VM i VMware samtidigt som alla mina andra 20 VMs var igång i produktion. Senast igår så packade jag upp 4 RARfiler samtidigt och Windows visade då toppar på 470 MB/s. Dock ska man nog ta det med en nypa salt. Mina första tester gjorde jag med XXX (minns inte namnet, men ett seiöst program för diskbench iaf) och då fick jag ut 350 MB/s. Dock har jag numera FreeNAS 11.1 och jag vet att en hel del förbättringar gjordes med ZFS i den versionen, så det kan ha blivit bättre.

Jag har en RAID10 med 8 diskar, och 10 GBe NFS mellan Server och FreeNAS. Inga diskar i servern. Min DC3710 är ~400 GB, minns inte exakt.

Sen vill jag påpeka att det inte är FreeNAS fel, det är snarare ZFS i sig själv som är krävande.

De RARfiler jag packade upp igår var totalt 5 TB med en konstant överföringshastighet på 350-470 MB/s.

Det ser iaf lite bättre ut, vi ser iaf 300-400 på flesta ställen vs de <200MB/s du hade innan.

Det kan ju vara så att din svajighet är en disk som börjar bli dålig, (då 2 st 2TB hade rasat lär de andra vara "på väg".), samt det verkar bli just svajigt när du läser från 2TB diskarna, då så de blir lite flaskhals.

@BerraBing På tal om firmware, har du dubbelkollat så "drive head parking" är avstängt på dina WD Green? Kika på attribut 193 (Load Cycle Count) via SMART.

https://support.wdc.com/knowledgebase/answer.aspx?ID=5357

titta i dmesg eller motsvarande att den inte har problem med WD-green diskarna - dom kan fula sig ganska ordentligt med långa svarstider och omskrivningar av sektorer upprepande för att de lästa är felaktiga utan att det syns något alls i SMART efteråt.

Hade ett sådant fall och det trögade ned NAS ordentligt utan att man kunde sätta fingret på det mha. de grafiska gränssnitten, SMART-värden där etc. utan blev till djupdykning i dmesg etc. och titta på lågnivå SCSI-kommandon...

@BerraBing Du kan inte förvänta dig att ZFS L2ARC (läs-cache) kommer hjälpa vid sekventiell skrivning. Enkelt sett så fylls denna cache endast vid repetitiv läsning av samma data innan denna data hunnit avlägsnas från primär cache (ARC) i RAM. Och den fylls långsamt. Samt överlever inte omstart.

Som @xxargs säger bör du undersöka dina WD Green mer i detalj.

Det är svårt för mig att göra någon direkt jämförelse med min egen server, men jag testade lite överföring till mina ZFS-pooler genom en Windows 10-VM på samma VMware-host som min FreeNAS-server. Jag testade överföring mellan pooler, samt från en RAM-disk i Windows. Ingen pool har cache (L2ARC) eller log (SLOG), bara fyra (raid10) eller två (raid1) diskar.

Jag skriver filer i ca 180-280 MB/s (snittar runt 230) till en 60% fylld pool bestående av 4x WD Black 640GB i mostvarande raid10 (stripe+mirror). Dessa diskar har över 7 år på nacken.

Jag får även ca 60% av ovan prestanda (90-120 MB/s), men med något större variation (ibland över 200 MB/s för flera GB i sträck), när jag skriver en likvärdig fil till min andra pool som består av två Seagate NAS 4TB i en enkel raid1 (mirror.) Denna pool är precis över 80% full vilket är övre gränsen för vad som rekommenderas för prestanda.

Ovan resultat är med jumbo frames (MTU 9000) och vmxnet3 på båda sidor. Kör jag över ett E1000E-interface utan jumbo frames (MTU 1500) i Windows, mot vmxnet3 utan jumbo frames i FreeNAS, så går prestandan ner ca 10-20%.

Jag har minskat ner maximal tid innan en transaktionsgrupp skrivs till disk, från 5 till 2 sekunder, vilket jag tror (kanske inbillar mig) ger mig mer jämn prestanda. (Jag sätter "loader" type tunable "vfs.zfs.txg.timeout" till 2.)

Det kan också vara bra att utesluta nätverksrelaterat strul. FreeBSD, som FreeNAS baseras på, kanske helt enkelt fungerar sämre än Linux i din miljö.

Hur snabbt skriver du data till din pool? Testa t.ex. genom att skapa ett dataset utan komprimering och skriva data dit via "dd". Se till att mängden data du skriver inte är för liten så den helt äts upp av en transaktionsgrupp (1/8 av RAM per default).

Exempel för 10 GB: dd if=/dev/zero of=/mnt/minpool/test/zerofile bs=1G count=10

Jag har ca 18 GB RAM för FreeNAS, så min skrivcache ligger runt 2 GB, men skrivs också ut efter max 2 sekunder. Data nedan är från 3 körningar per pool.

2 diskar i raid1: 83, 88, samt 89 sekunder för 10 GB (115-123 MB/s)
4 diskar i raid 10: 45, 58, samt 51 sekunder för 10 GB (176-227 MB/s)

Hur snabbt kan du skriva över nätverket? Testa genom att över nätverket skriva en högt komprimerbar fil till ett dataset med lz4-komprimering igång. T.ex. kan du kopiera över en eller flera av dessa filer med enbart 0:or till btrfs-poolen, eller en RAM-disk för den delen. Windows kommer skicka all data som den är, men FreeNAS kommer applicera sin enkla, och i det här fallet extrema, komprimering, så du kommer i stort sett se hur snabbt du kan föra över i absolut bästa fall till en blixtsnabb pool.

Att direkt i FreeNAS skriva en fil med bara nollor till en pool med lz4-komprimering tar för mig ca 4-5 sekunder, dvs runt 2 GB/s.

För min even del verkar min Windows-VM slå i taket vid en snitthastighet på ca 250 MB/s från RAM-disk till FreeNAS via både SMB och iSCSI. För SMB ser jag en initial burst på 1-2 sekunder med nära dubbla hastigheten, oklart vad det kommer från. För iSCSI ser hastigheten ut att börja lågt för att sedan rampa upp mer långsamt.

Det här blev längre än jag tänkt mig... Hoppas det hjälper någon.