SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
Cool artikel! Ze hebben er ook echt over nagedacht hoe ze deze data naar buiten moeten brengen zonder dat mensen te snel conclusies trekken
Even niets...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| [root@zfsguru ~]# /services/owncloud/service_install.sh * installing service owncloud * installing packages * package mp3info note: package mp3info is already installed; skipping... * package php5-ctype note: package php5-ctype is already installed; skipping... * package php5-curl note: package php5-curl is already installed; skipping... * package php5-dom note: package php5-dom is already installed; skipping... * package php5-fileinfo note: package php5-fileinfo is already installed; skipping... * package php5-hash note: package php5-hash is already installed; skipping... * package php5-iconv note: package php5-iconv is already installed; skipping... * package php5-json note: package php5-json is already installed; skipping... * package php5-mbstring note: package php5-mbstring is already installed; skipping... * package php5-mysql note: package php5-mysql is already installed; skipping... * package php5-pdo note: package php5-pdo is already installed; skipping... * package php5-pdo_mysql note: package php5-pdo_mysql is already installed; skipping... * package php5-pdo_sqlite note: package php5-pdo_sqlite is already installed; skipping... * package php5-simplexml note: package php5-simplexml is already installed; skipping... * package php5-sqlite3 note: package php5-sqlite3 is already installed; skipping... * package php5-xml note: package php5-xml is already installed; skipping... * package php5-zip note: package php5-zip is already installed; skipping... * package php5-zlib note: package php5-zlib is already installed; skipping... * executing post-installation script * downloading Owncloud version 5.0.12 /tmp/owncloud.tbz 100% of 14 MB 255 kBps 00m58s * checking SHA256 hash to verify integrity of downloaded tarball ERROR: Owncloud tarball fails SHA256 checksum; installation failed! ERROR: script returned error code 1 ABORTING installation of own cloud |
1
2
| [root@zfsguru ~]# sha256 /tmp/owncloud.tbz SHA256 (/tmp/owncloud.tbz) = b1aafcba4823c011b19b60353394d81455e2b3e9c169d4e444b27c740695ed7a |
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| config.status: linking src/makefiles/Makefile.freebsd to src/Makefile.port ===> Building for postgresql90-client-9.0.14 prereqdir=`cd parser/ >/dev/null && pwd` && \ cd ../../src/include/parser/ && rm -f gram.h && \ ln -s "$prereqdir/gram.h" . prereqdir=`cd utils/ >/dev/null && pwd` && \ cd ../../src/include/utils/ && rm -f fmgroids.h && \ ln -s "$prereqdir/fmgroids.h" . gmake -C utils probes.h gmake[1]: Entering directory `/usr/ports/databases/postgresql90-client/work/postgresql-9.0.14/src/backend/utils' dtrace -C -h -s probes.d -o probes.h.tmp dtrace: failed to compile script probes.d: "/usr/lib/dtrace/psinfo.d", line 88: failed to resolve type kernel`struct thread * for identifier curthread: Module is no longer loaded gmake[1]: *** [probes.h] Error 1 gmake[1]: Leaving directory `/usr/ports/databases/postgresql90-client/work/postgresql-9.0.14/src/backend/utils' gmake: *** [utils/probes.h] Error 2 *** [do-build] Error code 2 Stop in /usr/ports/databases/postgresql90-client. *** [install] Error code 1 Stop in /usr/ports/databases/postgresql90-client. *** [lib-depends] Error code 1 Stop in /usr/ports/databases/php5-pdo_pgsql. *** [run-depends] Error code 1 Stop in /usr/ports/www/owncloud. [root@zfsguru /usr/ports/www/owncloud]# |
[ Voor 32% gewijzigd door ]Byte[ op 12-11-2013 18:10 ]
duidelijk ja mogelijk nee.
als je wat wil toevoegen.
Indeed it is! LZ4 maakt compressie weer interessant. Na het debacel van deduplication waar veel thuisgebruikers uiteindelijk weinig aan hadden, is dit een veel interessantere manier om wat extra opslag te genereren, zonder veel negatieve bijeffecten. Geen lagere disk I/O, geen absurde RAM-eisen en goed schaalbare CPU-load. Bijna perfecte compressie zou ik zeggen.
Gewoon door er data naartoe te kopiëren van de ene naar de andere pool, en dan met gstat en top de disk I/O en CPU load bekijken. Oldschool.
Zie boven; gewoon een benchmark starten en met gstat de disk load bekijken. Client-side benchmarks zoals CrystalDiskMark zou ook kunnen, maar dan zou ik één grote testrun doen ipv 5 met een veel hogere testsize. Helaas gaat CDM maar tot 4GB ofzo. Dus misschien is een groot bestand van lokale SSD naar iSCSI-netwerkvolume kopiëren wel een betere handmatige methode.
Zeker nog minder. Want writes met qd=1 kunnen nog steeds gebuffered worden. Hardeschijven doen dit ook; random writes met qd=1 zijn om die reden sneller dan random reads met qd=1. SSDs doen dit door in één erase block een heleboek 4K/8K-writes te proppen, en dit remappen in de mapping tables. Hoppa, zo jas je die IOps er lekker doorheen!
Ehh, nee. Waar jij op doelt is een optimalisatie van de geom infrastructuur. Dit maakt het mogelijk IOps te schalen boven de 1 miljoen IOps - iets wat voorheen niet kon vanwege een bottleneck in de geom_up en geom_down modules. Nu er wordt bespaard op locks door een patch, is die bottleneck grotendeels weggenomen en kunnen IOps veel verder schalen.
Volgende keer liever een index, hoef ik niet 40 minuten te kijken.
TLER heb je niet nodig als je een goede implementatie heeft. Het is aan de host om de disk te resetten als het vindt dat het te lang duurt. Het recovery-by-default is dus een goed design technisch bekeken.
Voordat er zo'n 180-graden gedraaid advies uit zou rollen, zouden we toch eerst meer duidelijkheid moeten krijgen of wat die knakker in dat youtube-filmpje roept ook allemaal van klopt. In het bijzonder, of het ook van toepassing is op FreeBSD operating systems. Want dat waag ik dus te betwijfelen. En als dat klopt, dan hoeven we het advies helemaal niet aan te passen en is het uitschakelen van TLER nog steeds de juiste keuze voor een thuis NAS waarbij een korte service interruption ondergeschikt is aan het intact houden van je data bij verlies van redundancy.
Ik had exact dezelfde vragen en ook mijn hardware is vergelijkbaar. Ik heb zelf voor Linux (ubuntu 12.04.3 / debian) gekozen ivm flexibiliteit en community. ZoL voldoet prima voor mij. Ik heb (daar een x3 het ondersteunt ) ook voor ecc ram gekozen.
morgen verder.
Je hebt twee logins, admin en root. De ene heeft de CLI de andere niet. Ik dacht dat als je echt root wilt spelen je zelfs beter als admin inlogde en vervolgens de boel sudo su'en.:
Hmmz, ik begrijp er niets van...
Ik heb Nexentastor geinstalleerd (community versie).
Ik heb een 2tal guides gevonden om mijn FC HBA in Target mode te zetten (andere driver laden).
Echter, wanneer ik via SSH inlog, herkent de CLI geen van de commando's.
Het zal wel iets stoms zijn
Sommige zaken kan je niet met een paar regels afdoen.
Nee
In iedere productie omgeving wil je niet dat de storage minuten blijft hangen. Als je een desktop hebt met 1 drive zonder redundancy is het anders. Ook heb ik uitgelegd dat andere componenten als ESXi en guest OS's niet goed reageren op lang io timeout's, zonder allerlei tweaks.
Ik hoop dat je mijn uitleg nogmaals wil lezen. Want de meeste FS zijn niet afhankelijk van timeouts, net als ZFS.
Dit is al heel lang instelbaar. Alleen werd het vaak via custom firmware door de array fabrikant geregeld. Zakelijke gebruikers, kopen niet WD of Seagate. Maar kopen een totaal product van EMC of NetApp. Zij gaan niet zelf arrays samenstellen.
Ja, het stallen van io pipeline klopt. Ik heb hierboven en eerder een voorbeeld gegeven waar het wel degelijk iets uitmaakt. En ook gezegd dat het misschien niets uitmaakt, dat moet jij als gebruiker uitzoeken en testen. Bij standaard ESXi en guest OS's maakt het WEL wat uit.
Kies maar: of betere redundancy (triple mirrors ofraidz2 of raidz3) OF allemaal ellende omdat je zpool minuten lang hangt.
Heeft niks met ZFS te maken. Wordt geregeld in de disk en hba drivers. Zie eerdere post voor meer details.
Retry strategieen zitten in de disk en hba driver en drive firmware. De drivers zijn open source, als jij een eigen strategie wil toepassen, ga je gang. Dat is het mooi van open source. Maar denk even goed na voordat je daaraan begint. Kan jij een betere strategie ontwikkelen dan de duizenden mensen die zich de laatste 20 jaar hiermee bezig hebben gehouden. Je data verlies los je op met een extra drive en daarna eventueel betere drives. Voor iets meer dan 100 euro ben je klaar. En wat als je je zpool verliest? Je hebt toch backups?
Die onderliggende lagen zijn GEOM en CAM. GEOM is al heel oud, FreeBSD 5.0. CAM pas sinds FreeBSD 8.0 Beide zijn goede frameworks. Persoonlijk denk ik dat CAM een hogere waarde heeft dan GEOM. CAM heb je altijd nodig GEOM niet. CAM houd net zo vast aan SCSI als wie dan ook. Die oude systemen zijn een stuk robuster dan CAM en GEOM als je kijk naar de hoeveelheid fixes. De oude systemen krijgen geen fixes omdat ze goed zijn, CAM en GEOM hebben nog lang niet dat niveau bereikt.
Dit is kul. Verdiep je er wat meer in voordat je dit soort uitspraken doet. Een PCIe SSD kan lagere latency en kan hogere doorvoersnelheden bereiken omdat het op de PCIe bus zit, die sneller is dan SAS of SATA en geen hba nodig heeft. Maar al deze apparaten hebben een driver die het als disk laat verschijnen. En hoe spreek je die aan? Via je storage laag.
Lees bovenstaande nog eens. Ik schreef dat voor de meeste mensen TLER wel van meerwaarde is. En ja het is een keuze die je zelf moet maken. Ik heb alleen uitgelegd wat de gevolgen zijn voor diverse setups als je wel of geen TLER hebt.
Alleen zal die timeout een hele kostbare device reset tot gevolg hebben. Het is niet hetzelfde als TLER. TLER is alleen een verkorte timeout voor lezen en schrijven. Die 'enterprise controllers' hebben dit soort settings ook niet nodig. De drives hebben aangepaste firmware en het OS regelt de rest.
[ Voor 9% gewijzigd door EnerQi op 14-11-2013 10:57 ]
Bij reguliere (hardware) RAID heb ik altijd gezien dat bij 1 leesfout de hele disk wordt afgeschreven en direct opnieuw wordt opgebouwd. Dit is wel een proces wat bij een RAID 1 array op een low-end LSI controller zich een aantal keer per dag afspeelde trouwens. ZFS schrijft de disk ook direct af en doet de resilver (out-of-the-box in FreeBSD iig) automatisch, maar er is niets dat je tegenhoudt om de disk in kwestie opnieuw op te nemen in de array.:
leuke inhoudelijke discussies maar de conclusie is mij nog niet duidelijk:
Je gebruikt TLER om een resposive systeem te houden (7 sec recovery ipv meer), daarna gaat ie een andere disk proberen.
Mijn vraag is wanneer de disk als "bad" aangemeld wordt. Na 1x een block niet kunnen lezen? Als dit namelijk bij 1x niet lezen gebeurd, vind ik het een groot risico. 1 fout komt "regelmatig" voor op een grote disk (soft error / niet kunnen lezen door demagnetisering) en zou hiermee de hele disk offline halen. Effectief heb je dus meer kans je array te verliezen.
Of kun je ergens instellen (nu of toekomst) wanneer ie als "bad" aangemerkt moet worden zonder programmeur te zijn
[ Voor 4% gewijzigd door Bigs op 14-11-2013 11:33 ]
Uiteraard, maar dat is vaak helemaal niet zo erg, zo lang het meer informatie of meningen aan het onderwerp toevoegt, alleen maar goed! Enigszins geïnformeerd zijn is daarbij wel zo fijn. Wel vind ik je vorm van schrijven enigszins dwingend overkomen, maar dat kan ook aan mij liggen.
Fijn, daar gaat de hele discussie om, maar naar mijn mening is het antwoord niet dermate simpel.
We hebben het hier dan ook niet om een zakelijke productie omgeving maar om 'huis' servers. Dan nog is de discussie ook voor de professionele wereld uiteraard interessant, maar het zijn 2 verschillende gebieden die wellicht een ander antwoord krijgen op dezelfde vraag. Ik ben blij dat je ons eventjes hebt uitgelegd hoe ESXi en een guest OS werkt, naar mijn mening heeft een draaiende VM en ESXi niet zoveel last van een tijdelijk hangend storage systeem zolang deze daar eventjes niets van vraagt of op staat te wachten. ESXi heeft juist heel erg goede recovery mechanismes tegen tijdelijk wegvallende disks. Maar dat het niet ideaal is, sure.
Waarom je het hier over een FileSystem hebt terwijl ik het over een hardware RAID controller heb weet ik niet helemaal. Timeouts zijn hoe dan ook nooit ideaal.
Heel goed, zo werken professionele systemen inderdaad al jaren, daarnaast is de SCSI/SAS instructie set een stuk uitgebreider. Maar, uiteindelijk zitten er dezelfde disks in, ze vragen er alleen 5x zoveel voor. Ook is het zo dat op de meeste consumenten schijven het tot voor kort instelbaar was via smartctl en dergelijke maar dat dit een reboot niet overleefde. Op Linux/BSD gebaseerde systemen is dat gelukkig niet zo erg omdat het tijdens elke boot opnieuw ingesteld kan worden.
Ik heb nooit beweerd dat dit niet uitmaakt, uiteraard is dat vervelend/naar. Maar zoals ik schreef zijn er situaties denkbaar waarbij het toch wenselijk is tegenover de andere optie, data verlies. Dus?
Volledig afhankelijk van de situatie en de waarde die je aan je data hecht. Voor thuis of in de zakelijke markt zijn die eisen compleet anders, mede met het prijskaartje wat er aan vast hangt. Koop dan een mooi HDS array met 100% uptime garantie!
Ja, en, dan, dus? Daar hebben we het toch juist over? Zeker als we kijken dat veelal ZFS word gezien als vervanging van een hardware RAID controller. Dat het in de werkelijkheid een filesystem is die ook voor bepaalde RAID functionaliteit zorgt is bijkomstigheid en niet zoals veel mensen het bekijken.
Dude, daar gaat de complete discussie toch niet over? Het gaat erover dat met de hardware die gemiddeld genomen gebruikt word door de mensen op dit forum (en de thuis ZFS situatie) hoe daar het beste mee om te gaan. Compleet nutteloze opmerking om dan te gaan roepen dat iemand maar zelf eventjes een AHCI driver moet gaan herschrijven.Retry strategieën zitten in de disk en hba driver en drive firmware. De drivers zijn open source, als jij een eigen strategie wil toepassen, ga je gang. Dat is het mooie van open source. Maar denk even goed na voordat je daaraan begint. Kan jij een betere strategie ontwikkelen dan de duizenden mensen die zich de laatste 20 jaar hiermee bezig hebben gehouden. Je data verlies los je op met een extra drive en daarna eventueel betere drives. Voor iets meer dan 100 euro ben je klaar. En wat als je je zpool verliest? Je hebt toch backups?
De oude systemen krijgen geen fixes omdat ze OUD zijn, zo werkt dat overal in de professionele wereld, zegt over het algemeen vrij weinig of niets over de kwaliteit ervan. Bewezen is wat anders dan kwaliteit overigens. Ook moeten bepaalde technieken met de tijd mee door immer groeiende capaciteit en I/O behoeften.
Pardon?
Dat ligt eraan over wat voor markt we praten. Praten we FusionIO of bijvoorbeeld een Violin Memory dan zijn er andere technieken nodig om een hogere performance te kunnen halen. http://www.fusionio.com/white-papers/beyond-ssd/ . Overigens is bij een PCIe SSD die kaart zelf de HBA. Verder is dit type PCIe controller sterk in opkomst voor bijvoorbeeld host based caching, of in nieuwere storage arrays zoals Pure Storage. Met de tijd mee gaan, SAS is leuk, maar zeker niet het einde.Exact het is een keuze die afhankelijk is van een mening wat er belangrijker is, dat zijn we aan het discussiëren.
Zeker, helemaal waar. Gelukkig hebben we het nu over een discussie qua ZFS en de hier geregeld gebruikte hardware.
bedankt!
[ Voor 3% gewijzigd door Extera op 14-11-2013 14:37 ]
Even niets...
Maar ook dat vak gebied is al breed genoeg, een Netapp man is over het algemeen geen EMC man en andersom. Bedoel je wellicht de 8MB/sec waarde qua schrijven naar de L2ARC? Dat is een default waarde, die kun je aanpassen middels de volgende commando's: (Eventjes uit mijn eigen pruts documentatie gehaald van mijn implementatie van vorige week):
FF zonder gekheid. Los van hoe de discussie misschien loopt voel ik hier nu wel wat Tweaker bloed harder gaan stromen
@tvwes, jouw plan om data te classificeren is zeker valide, maar zelfs dat is voor veel mensen te duur. Die kunnen niet meerdere zpools gaan draaien met verschillende disk configuraties. Die willen gewoon met "The bare minimum" het onderste uit de kan halen. Natuurlijk mogen ze/we dan niet klagen. Maar we zijn wel Tweakers, en willen toch hier er dan met andere mensen over praten waardoor we misschien net wat meer snelheid behalen.
Vooral in mijn performance geval: Er klopt gewoon iets niet. Ik snap dat ik geen 90000 iops uit mijn ssd haal om diverse redenen, maar ik snap niet dat ik maar 8MB/s sequentieel haal.
De TLER discussie valt hier ook onder: Is het verplicht voor mensen die een bare minimum zpool (3-9 disks in 1 vdev) draaien met misschien een ZIL of L2ARC?
[ Voor 4% gewijzigd door FireDrunk op 14-11-2013 16:02 ]
Even niets...
[ Voor 38% gewijzigd door FireDrunk op 14-11-2013 16:08 ]
Even niets...
[ Voor 13% gewijzigd door Quindor op 14-11-2013 16:19 ]
) op NFS staan, en logischerwijs niet in een iSCSI volume. Installatie van zo'n ISO vanaf NFS richting iSCSI is dus ook traag.[ Voor 4% gewijzigd door FireDrunk op 14-11-2013 16:23 ]
Even niets...
Perfect lijstje!
[ Voor 73% gewijzigd door FireDrunk op 14-11-2013 16:46 ]
Even niets...
Geen flauw idee. Ik heb dan ook WD Reds met TLER
(en ik weet niet zeker of dat wel een reactie op mij moest zijn).[ Voor 4% gewijzigd door Durandal op 14-11-2013 16:51 ]
[ Voor 18% gewijzigd door Quindor op 14-11-2013 21:05 ]
Test name Latency Avg iops Avg MBps cpu load 4K Random Writes 23.38 1368 5 1%
Test name Latency Avg iops Avg MBps cpu load 4K Random Writes 233.75 136 0 0%
Test name Latency Avg iops Avg MBps cpu load 4K Random Writes 41.66 767 2 0%
[ Voor 26% gewijzigd door FireDrunk op 15-11-2013 10:06 ]
Even niets...
[ Voor 29% gewijzigd door Quindor op 15-11-2013 10:13 ]
[ Voor 29% gewijzigd door Quindor op 15-11-2013 13:01 ]
SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
Welk OS/software gebruik je? Je drukt ergens op; ZFSGuru?
)
SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
SMA SB5.0 + 16x Jinko 310wp OWO + 10x Jinko 310wp WNW |--|--| Daikin 4MXM68N + 1x FTXA50AW + 3x FTXM20N
Er zijn gevallen waar het nog steeds uit kan maken. Het ligt heel erg aan de characteristieken van de SSD's en waar de pool voor gebruikt word.
Hahaha, ik verander mijn post om 'meerdere' erbij te zetten en vervolgens lees ik jou post die dat ook omschrijft. Helaas is de doorvoer van zo'n DDRdrive niet zo geweldig maar de latency is wel super.
Is natuurlijk moeilijk met support-contracten en het doe-het-zelven dat erbij komt kijken.:
[...]
Hahaha, ik verander mijn post om 'meerdere' erbij te zetten en vervolgens lees ik jou post die dat ook omschrijft. Helaas is de doorvoer van zo'n DDRdrive niet zo geweldig maar de latency is wel super.
Wel top dat je zoveel ervaring hebt met Enterprise ZFS systemen! Ik kom ze nog niet zoveel tegen, hier en daar een verdwaalde Nexenta op basis van SuperMicro systemen maar verder nog niet echt. Jammer, aangezien het echt mooi spul is, maar veelal hebben de grotere storage vendors nog een te grote voet in de deur (hoofd) zodat ze niet zomaar verdwijnen. Maar dat gaat komende jaren wel goed komen verwacht ik.
:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
:strip_icc():strip_exif()/u/180748/avatar%2520nieuw%252060x60.jpg?f=community){kind=avatar}
/u/217664/crop57a47149436c0_cropped.png?f=community)
:strip_icc():strip_exif()/u/10414/crop5817c0657774d_cropped.jpeg?f=community)
/u/116403/crop64cfe7aeafeb6_cropped.png?f=community)
:strip_icc():strip_exif()/u/17654/gertus_icon.jpg?f=community){kind=icon}
/u/102334/avatar_mini.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/101865/crop5e04c97889698_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/121740/avatar.jpg?f=community){kind=avatar}
/u/170728/owl.png?f=community)
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)