Het grote ZFS topic

[Thralas]

Min-of-meer.

De essentie blijft dat een HDD voor iedere random seek (= metadata tag read) ~8 ms nodig heeft, omdat hij nu eenmaal op 7200 RPM draait.

Dus dan is de theoretische upper bound voor (puur) random IOPS ~126 voor een enkele disk. Met de zaken waar je nu aan het tunen bent valt er wellicht wel wat aan te schaven om dichterbij het theoretische maximum te komen, maar dat is aanmodderen in de marge als je bedenkt dat een SSD minimaal een factor 100 sneller is in random I/O. Dat lijkt me dan ook waar de oplossing ligt.

[Mr.Sun]

@FireDrunk

Ja danku. Ik maak hier nu ff werk van omdat het (1) nu nog kan, als de bak vol staat doe je geen expirimenten meer... (2) ik nieuw hierin ben en vind dat ik wel goede controle moet hebben over het systeem (3) ik het een uitdaging vind om dit middels de tech van nu te realiseren en (4) enige ict nurdiness mij ook niet ontbreekt... ;-)

Ik moet wel naar een afronding toe...

Snelheid van hele-files lezen ben ik niet bezorgd over:

Ik gebruik steeds 20GB testfolders (met daarin allerlei avg bestandgroottes). Zorg steeds voor lege ARC door reboot.
En die seektime/latency zal nog wel iets verslechteren door wat meer verspreiding van file-blocks/minder sequentieel draaien, maar ik denk dat de snelheid van nu (ca 500 read/600 write) nog wel wat verbetert (pool is nu 4 eenheden tbv data en 4 tbv rundancy en het data-deel gaat naar 8 eenheden). Pool is nu 2x4 disks en gaat naar 2x 6 disks.

Die snelheid van nu (bij hele-files lezen dus) zal ook wel 'ondanks dezelfde hoge latency' zijn maar worden gecompenseerd door het sequencen (ik begrijp dat dit gedrag is van ZFS)(dat bij volle pool minder wordt..).

Op het moment dat de pool 'versnippering' toont (kan je volgens mij laten scannen?) denk ik dan aan bijv mappen verplaatsen/herschrijven op de pool (danwel tussen NAS en back-up).

Dus tikkie meer latency...muh... en tikkie meer leestijd... muh.. Inderdaad.


Die '575 IOPS bij QD32' etc is dus vanuit de gedane testen zoals gedocumenteerd in die link.

Ik zelf zie dus IOPS per disk van ca 500 in de Reporting in de GUI.
Bij het hele-files lezen.
(je ziet de grafiek direct loodrecht omhoog schieten bij aanvang tesrun en weer neerploffen aan het eind).

Stabiel beeld bij elke, apart gedraaide run.

Bij het writen IOPS van ca 1200 dus.

Maar ik ben dus niet bezorgd over dat hele-files lezen.
Daar zijn er voldoende mogelijkheden om het te beheersen.


Tags lezen/schrijven is dus wél nog erg traag.

Ik zou dus als eerste wel willen kunnen zien wat de io-depth / queue-depth is, van gedane runs.
(dan weten we zeker dat het om hoge QD dus hoge latency gaat).

Kan dat met die iostat command?

[Thralas]

Zie de handleiding van zpool. Bijvoorbeeld:

zpool iostat -lqv 1

Lijkt me bijvoorbeeld vrij nuttig.

[Mr.Sun]

@Thralas

Ja in het begin van dit projektverhaal heb ik genoemd dat die tags op snellere dragers zetten in wezen de beste oplossing is maar ik wilde eerst stilstaan bij de mogelijkheden om de diskpool te optimaliseren.

Ik heb dat linkje dat je stuurde nog niet bekeken.
Maar ik dacht ongeveer langs dezelfde lijnen als die jij noemt:
1) ofwel specifieke manier van file-caching gebruiken (ri ARC/RAM+SSD/L2ARC)
2) danwel baseren op gebruik Metadata (ri ARC/L2ARC cq Metadata-VDEV).

1) Specifieke manier van file-caching gebruiken

Enerzijds makkelijk want je hoeft alleen maar die tags te lezen en ze gaan in de ARC/L2ARC...

Maar... er ook weer net zo makkelijk uit... want de ARC/L2ARC is niet kieskeurig en elke nieuwe of meer frequent gebruikte file drukt de bestaande inhoud uit de ARC/L2ARC.

Je kán wel iets verzinnen nl. dat je (1) alles op blocksize 64kB zet (2) alle tags leest en dus in ARC/L2ARC trekt en (3) daarna het systeem op metadata only zet.

Alleen heb je dan (ook bij 64kB-blocks) nog steeds veel TB's aan L2ARC nodig (en gaat dat in verhouding met de ARC-size dan wellicht minder goede performance geven?) maar bovenal gaat volgens mij bij 'metadata only' de performance van het hele-files lezen onderuit (ws omdat de prefetch dan ook uit staat?).

In ieder geval lijkt mij dit niet optimaal. Jullie gedachten??


2) Baseren op gebruik Metadata

Zover ik nu kan overzien bevat de ZFS 'metadata':
- de blockpointers ('adreswijzers' van de file-blocks)
- allocatietabellen
- basis file-data (filename, filesize, date changed etc).

Deze metadata kan je bijv in ARC trekken (dmv find commando).

Wanneer je dan dus een folder opent met alleen die basis file-data als kolommen openstaand (in bijv file explorer), dan schiet die hele folder (ook al zijn het 2000 files) bijna instant op je scherm.

(en ik denk overigens ook wel wanneer de metadata enkel in de 'metadata-VDEV' staat, weet ik op het moment ff niet meer)

Wanneer je nu kunt regelen dat aan die velden van 'basis file data' ook een serie van 'overige file data velden' kunnen worden toegevoegd, dan is lijkt mij daarmee gewaarborgd dat 'tags lezen/schrijven' vlot verloopt.
Die 'overige file data' staat op dezelfde (header) locatie op de file/block, en is ook van hetzelfde type en omvang (enkel wat lettertjes en cijfertjes).

Metadata kan dus in de ARC getrokken (en daar 'gelockt' door een 'metamin' in te stellen).
En de andere (betere) oplossing is om deze in de metadata-VDEV/'special class'-VDEV te laten plaatsen (wat vanzelf gaat zodra je die installeert op je pool).

Is dat 'toevoegen aan metadata' niet de meest effectieve oplossing?
(vroeg hij zonder al te veel last hebbende van teveel kennis .. ;-)

[Mr.Sun]

@Thralas

Jij noemt dus oa de suggestie om (mbv een automatisch meelopend systeempje) te zorgen dat vanzelf/realtime er van de (aangewezen) pooldata er elders een cache-kopie wordt neergezet van het eerste en laatste datachunk/block.

Bij opvragen van de tagdata wordt deze vanzelf uit de cache-locatie gehaald.

Dat lijkt me ook een goeie gedachte.
Wel kan het zijn dat er nogal veel data dan op SSD's moet. Bij bs 1MB dus minimaal 2MB per file.
Bij 3 mio files dus 6TB aan SSD.
(terwijl de tagdata ca 100kB gemiddeld is)(vs 2MB die je dan cachet).

Dat 'splitfs' gaat die kant op als ik het goed zie/begrijp. Ik zie daar dat dit het mogelijk moet maken om van de pooldata idd een mirror te maken, waarbij elke file in chunks op 2e locatie wordt geplaatst.
Maar wel met alle chunks ook daar volgens mij?
(en dan heb je dus wél de mogelijkheid om indiv chunks op te roepen).

Maar dat zou dan betekenen dat de hele diskpool ook op SSD moet... ?
(dat zou je dan in een toevoeging nog moeten differentieren: 'alleen bepaalde chunks cachen'?)
Maar dit 'spitfs' moet sowieso nog wel in praktijk gezet zover ik kan overzien?

Is het niet makkelijker om gebruik te maken van de bestaande weg van de metadata?
(daar wat velden aan toe te voegen)

[P5ycho]

Ik zou zeker met een set mirrors testen, raidz is echt een compromis wat iops betreft.
Normaal trek je dit soort dingen in een database.

[ Voor 40% gewijzigd door P5ycho op 16-11-2020 00:01 ]

[FireDrunk]

@Mr.Sun Ik heb even die link naar tweaktown's benchmark er bij gepakt, en ik denk dat je een verkeerde conclusie hebt getrokken.

Die 575 IOPS, zijn geen random iops. Je ziet in het grafiek daarna een read latency bij QD32 van ~55ms.
Dat is maar 18 iops per seconde.

Ik denk dat je je er gewoon bij neer moet leggen dat je array gewoon niet sneller is
Een custom gebouwd software systeem wat alle tag data cached, en periodiek flushed naar de pool, en alleen als het nodig is data opvraagt van de pool, zou hierin helpen.

Maar dat is nogal wat programmeer werk.

[Paul]

Mr.Sun schreef op zondag 15 november 2020 @ 22:07:
Zorg steeds voor lege ARC door reboot.

Is dat slim? Dat gebeurt met je echte data ook niet. Nu heb je wel veel meer echte data dan testdata, dus mogelijk zou eigenlijk de ARC proportioneel moeten verkleinen, maar wat zijn de resultaten als je die reboot niet doet?

Mr.Sun schreef op zondag 15 november 2020 @ 22:45:
Ja in het begin van dit projektverhaal heb ik genoemd dat die tags op snellere dragers zetten in wezen de beste oplossing is maar ik wilde eerst stilstaan bij de mogelijkheden om de diskpool te optimaliseren.

Is dat een optie? Ik weet niet welke software je gebruikt / om wat voor data het gaat, maar als je de metadata in aparte bestanden kunt zetten (en zelf het pad op kunt geven; ik weet dat een EMC Isilon dit op file-niveau kan bepalen maar ZFS volgens mij niet) dan kun je die bestanden op een andere pool zetten inderdaad.

[Giesber]

Mr.Sun schreef op zondag 15 november 2020 @ 22:07:
(dan weten we zeker dat het om hoge QD dus hoge latency gaat).

Ik heb de indruk dat je nog altijd een hoge QD als iets slechts lijkt te zien. Dat hoeft niet zo te zijn, en een queue in de HDD is net uitgevonden om de performantie te verbeteren.

In jouw geval wil je een massa data opvragen, laat ons het simpel houden op 1000 sectoren. Als je die in een queue van 32 stompt zijn kan de HDD beginnen te kijken hoe hij die 32 het snelste kan ophalen. Als ie wat begint terug te geven stomp jij de queue weer vol. Als jij vervolgens zegt dat die queue de boel vertraagt (een volle queue *klinkt* inderdaad traag), en de queue op 1 zet, kan die HDD niet meer kijken hoe hij dat het snelste kan ophalen, hij geeft dat ene ding terug en vervolgens vraag jij het volgende op. Kortom, hoe groter de queue in de HDD, hoe meer die zelf kan beslissen hoe hij dat het snelste kan gaan ophalen. Aangezien je 1000 dingen wil vragen, gaat dat in principe zelfs het rapste zijn als je die 1000 in één keer aan je HDD zou kunnen geven, dan kan de HDD zelf kijken hoe hij dat het rapste voor elkaar krijgt. Een queue kan wél nadelig zijn als je al verder kan met het eerste stukje data. Als we in ons extreme voorbeeld een queue van 1000 hebben, en de HDD besluit dat de data het snelste kan teruggegeven worden door item 1 in die queue als laatste terug te geven, moet je dus wachten tot de hele queue is afgehandeld. Maar dat nadeel speelt pas als de volgorde van de data belangrijk is.

Op Wikipedia staat een afbeelding die de snelheidsverbetering van een queue op een HDD heel goed laat zien, op deze pagina.

Ik vermoed dat in jouw geval het beperken van de queue eerder een nadeel gaat zijn in plaats van een voordeel. Een grote queue heb je sowieso, de QD waar jij het over hebt bepaald enkel hoeveel van die queue er in je HDD's zit. En dat zou wel eens best zoveel mogelijk kunnen zijn in jouw geval. Hoewel je er prima mee mag experimenteren (misschien heb ik het wel mis), kun je je best niet te veel fixeren op die QD. De cijfers kunnen ook misleidend zijn, want met een kleine queue kan je sneller je data hebben. Maar intussen betekent die kleinere queue in je HDD's dat de queue in je OS gewoon groter is.

[Q]

@Mr.Sun Hallo, welkom op het forum, wij hebben elkaar al even gesproken, maar ik kon je door kennisgebrek helaas niet zo goed ondersteunen.

De essentie in mijn ogen is dat een RAIDZ2 met 8 x 5400 RPM schijven een random IOPS geeft van 1 schijf. De regel bij ZFS is: IOPs van 1 disk per VDEV.

In dit geval is de random IOPs performance bij 4K waarschijnlijk rond de 60 IOPs max. Dat is natuurlijk heel laag en niet lekker voor een toepassing met enorm veel files en veel - vermoedelijk - random operaties.

60 IOPs is bijna met pen en papier bij te houden, of met ponskaarten, zo langzaam is dat.

Je kunt het ook wel zien met een commando als:

code:

iostat -xm 5

De kolommen await_r en await_w laten de latency per IO zien en als dat boven de 20ms ligt dan is je storage gewoon de bottleneck.

Ik ga overigens de weddenschap wel aan dat een ouderwetse RAID6 op Linux met MDADM je al veel betere performance gaat geven. Ik zou het eens testen.

Het is heel gewoon in storage land dat als je met harde schijven werkt, dat je gewoon heel veel harde schijven in je storage stopt om een bepaald performance target te halen.

Het kan zijn dat je misschien 20TB nodig hebt, maar dat je een veelvoud aan capaciteit hebt. Die capaciteit kun je niet benutten en heb je ook niet nodig, maar je hebt de keiharde spindels nodig voor de performance.

En ik vrees dat dit bij jouw situatie ook het geval is.

SSDs zijn misschien nog even te prijzig om te performance problemen op te lossen. Maar om de gewenste performante te krijgen met schijven, ben je misschien ook een aardig centje kwijt.

Overigens, er staat me bij dat je wel getest had met mirrors en dat de performance niet heel veel beter was, maar dat weet ik niet meer precies. Echter, van 60 naar 240 IOPs random is een verbetering, maar nog steeds niet heel veel.

[ Voor 7% gewijzigd door Q op 16-11-2020 14:30 ]

[P5ycho]

Voor de read performance is een 4x 2-way mirror pool in theorie al 4x sneller met reads dan een 2x 4-way raidz2. Bij writes is dat de helft, 2x sneller. Zo te zien maakt het niet zoveel uit hoe snel een individuele file van de disk komt (assumptie, waar raidZ2 weer in het voordeel is) dus een test met een mirrored pool lijkt me relevant.
Daarnaast, zoals hierboven genoemd, meer spindels is meer IOPS. Dit schaalt prima.

[Mr.Sun]

Allen hartelijk dank voor de input.

Ik ben eerst nog ff bezig met het draaien van diverse testruns.
(int kader van: 'denken is mooi maar meten is weten').

I'll be back... ;-)

[ocaj]

Mr.Sun schreef op zondag 15 november 2020 @ 23:34:

Dat lijkt me ook een goeie gedachte.
Wel kan het zijn dat er nogal veel data dan op SSD's moet. Bij bs 1MB dus minimaal 2MB per file.
Bij 3 mio files dus 6TB aan SSD.
(terwijl de tagdata ca 100kB gemiddeld is)(vs 2MB die je dan cachet).

Daar gaat het dus mis, zoals ik al eerder zei: je gebruikt een blocksize van 1MB. ARC cachet op block-niveau (niet op fileniveau). Als je dus normaal gesproken alleen de 1e (+ eventueel laatste?) 100KB van een file nodig hebt omdat daar de tags in opgeslagen zijn, dan verspil je heel veel ARC-cache aan niet-tag-data.

Zet je de blocksize naar 64 of 128KB, dan pakt het al heel anders uit.
Je hebt het over 3miljoen files, dat is wel echt veel. Aan tag-data is dat dan (uitgaande van 1x128kb): 366GB. Dat is veel te veel voor RAM en ARC-only. Overweeg om voor inzet van ARC meer RAM te plaatsen dan de 32GB die je nu gebruikt (qua kosten wil je waarschijnlijk niet verder gaan dan 64 of 128GB) en vul de rest aan met een 512GB of 1TB SSD die je puur inzet als L2ARC. Het is cache dus je hebt geen redundantie nodig. Wat ik niet scherp heb is of je performance nog verbetert van 2 losse cache-devices.

Let dan wel op dat standaard de L2ARC slechts heel traag vult. Er zijn ontwikkelingen om de L2ARC persistent te maken, zodat je na een reboot die niet eerst opnieuw helemaal moet vullen, maar ik weet niet of dat al productie-rijp is. Anders zijn er wel wat tunables om de snelheid waarmee de L2ARC gevuld wordt te verhogen. Je zou die tijdelijk hoger kunnen zetten en dan wat "cache-vul"-scripts draaien die passen bij je gebruik.

Ik bedenk me net nog iets dat van invloed kan zijn: Wat voor software gebruik je voor het doen van de queries? In welke mate doet die software de queries allemaal sequentieel of zit daar ook een mate van parallellisme in? Het grootste deel van de tijd zit de software te wachten op disk I/O. Dat leent zich er dus behoorlijk goed voor om te paralleliseren. Samen met de opmerkingen van Giesber dat je misschien wel juist wil zorgen dat de QD van de schijven continu maximaal gevuld is geeft dat misschien ook een enorme performance boost? Zeker als je software sequentieel zou werken. (toegegeven, niet elke workload laat zich even goed paralleliseren, maar bij een dusdanig IO-intensief algoritme kan het zeker heel veel meer lonen om het algoritme te optimaliseren dan puur te focussen op de disk-performance).

(daarnaast, maar dat hadden anderen al aangegeven en bleek ook uit je eigen tests: laat raidz voor wat het is en ga voor zo veel mogelijk vdevs van 2 gemirrorde schijven. dat levert je de meeste iops op)

[Mr.Sun]

OK, even iets later maar toch vandaag maar ff een 'wrap-up'.

Afgelopen uren nog weer de nodige testen gedraaid en uiteraard ook de diverse inputs bekeken.

Hieronder spits ik het eerst ff toe op de kern, nl hoe krijgen we het tags lezen vlotter.
(en morgen ga ik ook nog ff in op wat andere goede punten die genoemd werden maar er niet meer toe doen).

1)
Firedrunk zei het ook al op wat andere manier:

de load hier (en bijna altijd) op de hard-disks maakt dat de queue-depth (QD) direkt naar max gaat.

Dus >> hoogste latency (niet 'IOPS rules maar latency').

(ik zie in de testing 'qlen' (queue-length=queue-depth) van 20 tot zelfs 60 per disk
(overigens niet met de gegeven iostat maar met: iostat -x -I da1 1)

>>files >> sequentieel >> 23ms ; op veel r/w

>>tags >> random >> 55+ms ; op 1 r/w.... (auw).

2)
55+ms >> 1000/55+ = max 18 IO per sec (IOPS) (yup: 18 IOPS...)

Dus.... "mirrors/meer VDEVs" etc = allemaal "proberen met 18 IOPS maal X iets zien te bereiken'…
(testen met 4 mirrors laten daarnaast ook geen betere tags/sec zien)
(ook testen met 8x in Raid0 evenmin)

(testen laten slechts 10% verbetering zien bij files r/w)
(maar ook al zou het wat helpen; enorm ineffectieve methode om iets meer IOPS te krijgen)
('alles kan met harddisks' maar ergens is het niet meer reeel natuurlijk)

3)
Dit soort data/stroom: random r/w + met met kleine files, moet niet op HDD maar op SSD
>> SSD kent geen latency (nihil)
>> ook bij max QD nog steeds top IOPS ("not latency but IOPS rules").

4)
Je ziet ook al wel dat er steeds meer SSD-inzet in het ZFS-based systeem mogelijk wordt
(eerder al SSD tbv de L2ARC, tbv ZIL en nu tbv 'Metadata-VDEV' en 'special class'-VDEV)

>> basisconcept wanneer je nu een nieuw systeem opzet moet m.i. zijn; alleen nog 'koude' en/of goed sequential draaiende data op harddisk
>> rest op SSD ('cheap' sata cq 'highpower' NVME) cq RAM.

5)
'Tagdata' is natuurlijk voor alle soorten data/NAS's van toepassing:
Audio-collecties, film/video-collecties, foto-collecties, tekening-collecties, etc etc
>> Dus het zou toch logisch zijn als er een standaard manier was om die tagdata op SSD te hebben ?

6)
2 meest logische wegen naar Rome meen ik:
1 Completeren van de ZFS-'metadata':
- Bevat nu dus alleen de basis file-data
- Op dezelfde locatie in de file-header staan die overige tag-data ('naam maker, jaartal, etc")
Handlen van metadata is al goed geregeld (ri ARC cq ri metadata-VDEV)

2 Programma'tje dat continue de tagdata naar een gekozen locatie cachet.
En (op achtergrond) update richting de diskpool/files).
(Thralas en Firedrunk ea noemden dit ook al).

Maar mijn inschatting is dat het het meest eenvoudig is om voort te borduren op het al lopende ZFS-'metadata'-gebruik? (en 'enkel' een aantal velden toevoegen daar?)

Wie kan daar iets zinnigs over zeggen?

[FireDrunk]

Ik vind punt 2 nog wel vreemd. Mirrors zouden eigenlijk altijd bijna 100% schaling moeten laten zien qua IOPS.
Als dat niet zo is, moeten we daar misschien toch eens naar kijken.

Kan je uitleggen wat je exact getest hebt?

Ik ben ook nog wel benieuwd naar hoe je de connectie maakt met clients, ik lees wel 10Gb, maar welk protocol? Windows SMB? Heb je NFS al eens geprobeerd? Staan dingen als Jumbo Frames aan?
Het is onwaarschijnlijk dat Jumbo Frames je ineens meer IOPS gaat geven, maar optimalisaties zijn natuurlijk altijd welkom.

Gister trouwens even met iozone op mijn eigen pool getest:

iozone -a -s 10g

        Iozone: Performance Test of File I/O
                Version $Revision: 3.429 $
                Compiled for 64 bit mode.
                Build: linux-AMD64

        Contributors:William Norcott, Don Capps, Isom Crawford, Kirby Collins
                     Al Slater, Scott Rhine, Mike Wisner, Ken Goss
                     Steve Landherr, Brad Smith, Mark Kelly, Dr. Alain CYR,
                     Randy Dunlap, Mark Montague, Dan Million, Gavin Brebner,
                     Jean-Marc Zucconi, Jeff Blomberg, Benny Halevy, Dave Boone,
                     Erik Habbinga, Kris Strecker, Walter Wong, Joshua Root,
                     Fabrice Bacchella, Zhenghua Xue, Qin Li, Darren Sawyer,
                     Vangel Bojaxhi, Ben England, Vikentsi Lapa.

        Run began: Mon Nov 16 07:58:42 2020

        Auto Mode
        File size set to 10485760 kB
        Command line used: iozone -a -s 10g
        Output is in kBytes/sec
        Time Resolution = 0.000001 seconds.
        Processor cache size set to 1024 kBytes.
        Processor cache line size set to 32 bytes.
        File stride size set to 17 * record size.
                                                              random    random     bkwd    record    stride
              kB  reclen    write  rewrite    read    reread    read     write     read   rewrite      read   fwrite frewrite    fread  freread
        10485760       4   595214   491669  1838962  1880717   263048    18880  1236126   1171757    420422   481354   457476  1834081  1861290
        10485760       8   695607   704668  2897200  3022669   518504    28475  2422150   2256752    532722   637920   545166  2860159  2989892
        10485760      16   794086  1212809  4073538  4172785  1013739    11982   293208    283175   1185585    15042    11561  2602673  2765983
        10485760      32    15301    23654  4219477  4787972  1837251     3708  1429017    158072   2265416    17581    14746   955293  1778941
        10485760      64    23771    29422   455498  2697121  2023230    10395   782569    604128   4133247    17245    16320    63560  6162004
        10485760     128   890662   809597  6259382  6866663  6447859   140165  5696246  17810025   6698745   696762   264311  6537945  6719345
        10485760     256   401666   324772  5624101  6842440  6706087   158882   638994   2226721   6499427    29551    38188  6804958  6449949
        10485760     512    99045   440635  5820640  6722275  6798657   846745  7313826  15957170   6875881   793085   664260  6740279  6144222
        10485760    1024   859896   818427  6151077  6528026  6498665   615432  6529371  16959620   6571437   582326  1228307  5627128  6325262
        10485760    2048   706990   775194  5382719  6030614  6651607   802770  7128485  16911291   6679751   790030  1264446  6007444  6496182
        10485760    4096   801974   461678  5914681  4931349  5713102   854098  4836103   9855410   5717703   995908  1002120  5898899  4930934
        10485760    8192   842932   446763  5389714  4966607  5556387   345704  5784745   7530990   5574993   406101   280667  4795770  5169419
        10485760   16384   702826   646659  5083610  5406000  5400690   640130  5064611   7384832   5500190   875032   645680  4303557  5314414

iozone test complete.

In de frewrite test (1 van de moeilijkste tests volgens mij), zie je bij 4 en 8k vrij hoge waardes, want caching (denk ik), maar bij de 16k test, zie je de pool al flink inzakken. Dat is eigenlijk het slechtste punt van mijn array. Daar haal ik dus 11561KB/s, bij records van 16k is dat dus ~722 iops. Mijn pool bestaat uit 6 * 2.5" 2TB schijfjes in RAIDZ2, en het zijn ook nog eens SMR schijven.

Ik zou dezelfde test graag met een veel grotere size willen doen, maar mijn pool is vrij vol, dus dat gaat niet zo goed

Zojuist ook even FIO gedraait, die laat weer een heel ander beeld zien:

fio --name=randread --rw=randread --direct=1 --ioengine=libaio --bs=8k --numjobs=16 --size=10G --runtime=600 --group_reporting

Dit is dus een randomread test, blocksize 8k, 16 concurrent threads, met voor elke thread een 10G test file. De totale spanne van de test is dus 160GB, waar die bij iozone 'maar' 10GB was. Hier zie je de hoeveelheid IOPS al vele malen lager zijn.
Heeft natuurlijk ook met de benchmark te maken.

Jobs: 15 (f=15): [r(15),_(1)][94.0%][r=1097KiB/s][r=137 IOPS][eta 00m:38s]
randread: (groupid=0, jobs=16): err= 0: pid=21272: Tue Nov 17 08:26:02 2020
  read: IOPS=2291, BW=17.9MiB/s (18.8MB/s)(10.5GiB/600133msec)
    slat (usec): min=2, max=3516.9k, avg=6572.29, stdev=43065.53
    clat (nsec): min=550, max=576206, avg=896.47, stdev=1386.78
     lat (usec): min=2, max=3516.9k, avg=6573.32, stdev=43066.52
    clat percentiles (nsec):
     |  1.00th=[  564],  5.00th=[  572], 10.00th=[  620], 20.00th=[  636],
     | 30.00th=[  644], 40.00th=[  644], 50.00th=[  652], 60.00th=[  652],
     | 70.00th=[  660], 80.00th=[  668], 90.00th=[  692], 95.00th=[  908],
     | 99.00th=[ 6624], 99.50th=[ 6816], 99.90th=[ 7392], 99.95th=[ 8384],
     | 99.99th=[29568]
   bw (  KiB/s): min=   12, max=576720, per=6.78%, avg=1241.87, stdev=21893.85, samples=17109
   iops        : min=    1, max=72090, avg=154.87, stdev=2736.75, samples=17109
  lat (nsec)   : 750=94.47%, 1000=0.69%
  lat (usec)   : 2=0.16%, 4=0.36%, 10=4.29%, 20=0.02%, 50=0.02%
  lat (usec)   : 100=0.01%, 250=0.01%, 500=0.01%, 750=0.01%
  cpu          : usr=0.03%, sys=0.39%, ctx=65043, majf=0, minf=175
  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1375055,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
   READ: bw=17.9MiB/s (18.8MB/s), 17.9MiB/s-17.9MiB/s (18.8MB/s-18.8MB/s), io=10.5GiB (11.3GB), run=600133-600133msec

De average latency van mijn pool is dus 65ms, met een max latency van 3.5 seconde
Als je kijkt naar 99% percentielen (wat soms een redelijker getal is dan het gemiddelde), zie je dus dat 99% van de tijd een IO operatie gecomplete wordt in 66ms.

De IO depth per thread was nooit hoger dan 1, dus er is hooguit een queue depth van 16 te bereiken. Veel hoger zal denk ik ook geen zin hebben (gehad).

Uiteindelijk is het gemiddelde aantal IOPS dus op 137 IOPS uitgekomen (zie bovenin).
Dat komt neer op ~35 iops per schijf (4 data schijven, 2 parity doen niet mee)

[ Voor 101% gewijzigd door FireDrunk op 17-11-2020 08:33 ]

[Paul]

Mr.Sun schreef op dinsdag 17 november 2020 @ 01:26:
'Tagdata' is natuurlijk voor alle soorten data/NAS's van toepassing:
Audio-collecties, film/video-collecties, foto-collecties, tekening-collecties, etc etc
>> Dus het zou toch logisch zijn als er een standaard manier was om die tagdata op SSD te hebben ?

Ja, dat heet een database Alle tags bij elkaar, in plaats van decentraal opslaan bij allemaal data die je niet nodig hebt (voor de verwerking van de tags).

Die data in een gestructureerde database zetten heeft verder als voordeel dat je de metadata niet steeds hoeft te parsen. Als je alles wil hebben van artiest X dan hoef je niet van 3 miljoen bestanden 100 KB in te lezen, te parsen op zoek naar het juiste veld, en dan de inhoud te bekijken. Met een database kijk je in de index van artiesten en krijg je zo de lijst met bestanden terug die daar aan voldoen.

De meeste mensen hebben op hun NAS geen 3 miljoen bestanden / 50 TB muziek, en ze zitten ook niet de hele dag steeds opnieuw alle tags uit te lezen

[Q]

@Mr.Sun

Ik heb nog eens nagedacht over het probleem wat je probeert op te lossen.

De schaal waarop je aan het opereren bent, miljoenen files uitlezen van tientallen MBs groot, is niet iets wat veel partijen doen, denk ik. Ook al lees je alleen de header data, al die files uitlezen, dat is gewoon heel veel storage I/O.

En als ze dat doen, dan hebben ze ook de resources (compute en storage power om dat te doen).

Je gaat erg ver in je tests maar je probeert in mijn beleving iets te bewerkstelligen wat jouw huidige hardware, in combinatie met ZFS gewoon niet gaat leveren.

Ik zie ook niet dat je ooit met Linux en RAID6 hebt getest overigens. Ik zou al forse snelheidswinst verwachten met zo'n setup, maar je kunt de wetten van de natuurkunde niet tarten. Je gaat nooit de gewenste performance halen uit 8 x 5400 RPM schijven.

Je komt al in het territorium van een entry-level SAN, met misschien wel honderden 10K RPM schijven om de gewenste performance te halen.

Maar de vraag is of deze performance ook echt nodig is.

Ik denk dat de suggestie van @Paul in jouw geval misschien wel de juiste is. Ik denk dat je beter af bent met een geschikte applicatie waarin je alle metadata kunt queryen en bewerken. 's Nachts kun je dan een batch job laten lopen om wijzigingen door te voeren, of om nieuwe (meta)data te importeren.

Echter, ik heb onvoldoende inzicht in de workflow om te bepalen of dat werkelijk een werkbare situatie oplevert.

Ik denk - maar daar mogen de ZFS experts ook iets over zeggen - dat ZFS in jouw specifieke geval misschien niet ideaal is. Maar dat is in geen enkel opzicht een minpunt voor ZFS want dit is een speciale situatie.

Veel RAM in de server of een groot L2ARC cache lijkt mij niets te helpen, want het gaat om metadata van muziek bestanden, en vanuit het perspectief van ZFS is dat gewoon 'data'. Wat zeker gaat helpen is 50 TB aan RAM, maar ik weet niet of je die kosten ooit gaat terug verdienen.

[FireDrunk]

@Q Ik ben het grotendeels met je eens. Al verwacht ik niet dat Linux MD RAID6 significant betere prestaties gaat opleveren. Zijn workload is vooral read-intensive, en daar verschillen ZFS en MD in mijn ogen niet veel. Qua writes zal het mogelijk wel iets verschillen, vanwege het copy-on-write karakter van ZFS.

Aan de andere kant: Hij heeft sync uit staan, waardoor ook hier alle writes gecached kunnen worden in een transactiegroep. Iets wat MD helemaal niet kent. In een aantal gevallen zal ZFS dus waarschijnlijk meer optimalisaties kunnen doen binnen de transactie groep dan dat MD zou kunnen.

De beste performance haalt @Mr.Sun denk ik door een combinatie van ZFS en een goede applicatie laag die specifiek tags in geheugen vast houdt, zoals @Paul en @Q terecht opmerken.

Veel RAM tbv ARC en/of losse devices voor L2ARC helpen alleen als die applicatie de ARC/L2ARC ook met rust laat voor de tags. In dat geval kunnen ARC en L2ARC volledig ingezet worden voor de gewone data, en zal het uiteindelijk met de meestgebruikte data gevuld worden. Wat de real-world winst daarvan is, hangt af van de intelligentie van de software die je er tussen zet.

[Q]

FireDrunk schreef op dinsdag 17 november 2020 @ 14:48:
@Q Ik ben het grotendeels met je eens. Al verwacht ik niet dat Linux MD RAID6 significant betere prestaties gaat opleveren. Zijn workload is vooral read-intensive, en daar verschillen ZFS en MD in mijn ogen niet veel. Qua writes zal het mogelijk wel iets verschillen, vanwege het copy-on-write karakter van ZFS.

Misschien zit ik er naast, maar naar mijn weten geld de volgende regel voor zowel reads als writes.

Effectieve random IOPs is dat van één disk per VDEV ongeacht hoeveel disks er in een VDEV zitten.

Writes kun je accelereren door een SLOG op basis van SSDs toe te voegen. Maar reads niet, dus dan moet je hopen dat je kunt cachen of toch voor mirrors kiezen voor meer IOPs.

Aan de andere kant: Hij heeft sync uit staan, waardoor ook hier alle writes gecached kunnen worden in een transactiegroep. Iets wat MD helemaal niet kent. In een aantal gevallen zal ZFS dus waarschijnlijk meer optimalisaties kunnen doen binnen de transactie groep dan dat MD zou kunnen.

Ik denk dat dit nog niet eens zoveel uit gaat maken. Als je de de bitmap verwijdert van je MDADM array heb je grofweg het zelfde effect. Ik heb er eens wat mee gespeeld en gedocumenteerd.

De beste performance haalt @Mr.Sun denk ik door een combinatie van ZFS en een goede applicatie laag die specifiek tags in geheugen vast houdt, zoals @Paul en @Q terecht opmerken.

Veel RAM tbv ARC en/of losse devices voor L2ARC helpen alleen als die applicatie de ARC/L2ARC ook met rust laat voor de tags. In dat geval kunnen ARC en L2ARC volledig ingezet worden voor de gewone data, en zal het uiteindelijk met de meestgebruikte data gevuld worden. Wat de real-world winst daarvan is, hangt af van de intelligentie van de software die je er tussen zet.

Ik ben geen expert in de exacte werking van het (L2)ARC algoritme, maar ik heb sterk de indruk dat ook ZFS niet echt gaat helpen omdat het om zoveel data gaat, dat continue alles uit de cache wordt gegooid.

Het algoritme moet dan echt zo werken dat alleen de blocks worden gecached van de files waar metadata in zit en ik betwijfel of dat zo werkt.

Wat een enorm verschil zou kunnen maken: hoe werkt de software die de tags uitleest: als deze software echt alleen I/O requests doet op de eerste paar KB met de muziek metadata, dan geef ik ZFS al heel veel meer kansen. Maar dat soort I/O wordt ook gewoon door de Linux kernel gecached.

Het zou dus interessant kunnen zijn om te zien hoeveel I/O per muziek file naar disk wordt gestuurd om de tags te lezen. Wordt de hele file gelezen (eventueel ook door read-ahead parameters, wat je hier niet wilt) of alleen dus de eerste paar KB.

Stel nu dat de tool toch de hele file eerst opvraagt in zijn geheel, dan zou het zoeken naar een andere tool die alleen naar de header kijkt al enorm veel verschil uitmaken.

Overigens zou fors meer RAM dan zeker uit gaan maken, maar ik weet niet hoeveel nodig is.

Maar om een idee te geven: voor waarschijnlijk minder dan 1 - 1.5K Euro's heb je een DL380 waar je zeker - afhankelijk van het chassis - 12 x 3.5"" schijven in kunt stoppen en waar ook dan 256 GB aan RAM ofzo in kan.
Als je met dat soort brute-force acties de boel gewoon kunt oplossen, prima.

Maar het hangt allemaal heel erg af van de software, hoe die deze files inleest.

[FireDrunk]

Q schreef op dinsdag 17 november 2020 @ 16:41:
[...]


Misschien zit ik er naast, maar naar mijn weten geld de volgende regel voor zowel reads als writes.

Effectieve random IOPs is dat van één disk per VDEV ongeacht hoeveel disks er in een VDEV zitten.

Writes kun je accelereren door een SLOG op basis van SSDs toe te voegen. Maar reads niet, dus dan moet je hopen dat je kunt cachen of toch voor mirrors kiezen voor meer IOPs.


[...]


Ik denk dat dit nog niet eens zoveel uit gaat maken. Als je de de bitmap verwijdert van je MDADM array heb je grofweg het zelfde effect. Ik heb er eens wat mee gespeeld en gedocumenteerd.


[...]


Ik ben geen expert in de exacte werking van het (L2)ARC algoritme, maar ik heb sterk de indruk dat ook ZFS niet echt gaat helpen omdat het om zoveel data gaat, dat continue alles uit de cache wordt gegooid.

Het algoritme moet dan echt zo werken dat alleen de blocks worden gecached van de files waar metadata in zit en ik betwijfel of dat zo werkt.

Wat een enorm verschil zou kunnen maken: hoe werkt de software die de tags uitleest: als deze software echt alleen I/O requests doet op de eerste paar KB met de muziek metadata, dan geef ik ZFS al heel veel meer kansen. Maar dat soort I/O wordt ook gewoon door de Linux kernel gecached.

Het zou dus interessant kunnen zijn om te zien hoeveel I/O per muziek file naar disk wordt gestuurd om de tags te lezen. Wordt de hele file gelezen (eventueel ook door read-ahead parameters, wat je hier niet wilt) of alleen dus de eerste paar KB.

Stel nu dat de tool toch de hele file eerst opvraagt in zijn geheel, dan zou het zoeken naar een andere tool die alleen naar de header kijkt al enorm veel verschil uitmaken.

Overigens zou fors meer RAM dan zeker uit gaan maken, maar ik weet niet hoeveel nodig is.

Maar om een idee te geven: voor waarschijnlijk minder dan 1 - 1.5K Euro's heb je een DL380 waar je zeker - afhankelijk van het chassis - 12 x 3.5"" schijven in kunt stoppen en waar ook dan 256 GB aan RAM ofzo in kan.
Als je met dat soort brute-force acties de boel gewoon kunt oplossen, prima.

Maar het hangt allemaal heel erg af van de software, hoe die deze files inleest.

Als je sync uit hebt staan kun je zoveel IO kwijt als je transaction group toe staat. Als CPU, Memory en alle settings het toestaan, kunnen er miljoenen IO's in 1 group.
Problemen ontstaan daarna vaak. Er mogen niet meer dan 2 transacties lopen. 1 die gesynced wordt, en 1 die open staat. Als de eerste nog niet klaar is, mag de volgende nog niet open.

Als sync uit staan wordt een transactie volledig 'sequentieel'. Dat is niet dezelfde sequentieel als een hele file lezen. Maar de sequentieel van NCQ. Die is vele malen sneller dan random, maar niet zo snel als aangrenzende data.

Als zijn bereik gigantisch is per transactiegroep, en alle schijven moeten een maximale seek doen naar de volgende sector, zijn zowel de reads als de writes altijd duur. Daar veranderd een SLOG niets aan.

Wat in zulke gevallen kan helpen is grotere (en vooral langere) transactiegroepen toestaan. Vroeger was de timeout 15s ofzo dacht ik en ik meen tegenwoordig 5s.

Daar komt het vroegere "breathing" ook vandaan. Het syncen van de transactiegroep was de 'load' en het vullen plus wachten op de timeout de 'idle'.

mdadm synced altijd meteen (voor zover ik weet, op wat write caching na, iig geen tijdslimieten).
De bitmap is volgens mij vooral een allocatiefile waar info in staat over welke delen van de array bezet zijn, en is voor zover ik weet fundamenteel anders dan de ZIL.

Wat je dus wil om maximale performance er uit te halen, is een tool die 'weet' waar de data staat en alles sequentieel wegschrijft in grote batches. Daardoor verlaag je de track-to-track latency en worden transacties veel sneller gesynced.

[Q]

FireDrunk schreef op dinsdag 17 november 2020 @ 17:32:
[...]


Als je sync uit hebt staan kun je zoveel IO kwijt als je transaction group toe staat. Als CPU, Memory en alle settings het toestaan, kunnen er miljoenen IO's in 1 group.
Problemen ontstaan daarna vaak. Er mogen niet meer dan 2 transacties lopen. 1 die gesynced wordt, en 1 die open staat. Als de eerste nog niet klaar is, mag de volgende nog niet open.

Als sync uit staan wordt een transactie volledig 'sequentieel'. Dat is niet dezelfde sequentieel als een hele file lezen. Maar de sequentieel van NCQ. Die is vele malen sneller dan random, maar niet zo snel als aangrenzende data.4

Helder, maar voor mijn begrip: dit gaat met name over writes? Je ziet überhaupt dat random writes vaak beter performen dan reads want met writes kan storage 'liegen' over data --> wat je toestaat als je sync uitzet.

Storage kan echter nooit 'valsspelen' als het om reads gaat., maar daar ligt volgens mij in 'deze situatie' het performance probleem.

Als zijn bereik gigantisch is per transactiegroep, en alle schijven moeten een maximale seek doen naar de volgende sector, zijn zowel de reads als de writes altijd duur. Daar veranderd een SLOG niets aan.

Wat in zulke gevallen kan helpen is grotere (en vooral langere) transactiegroepen toestaan. Vroeger was de timeout 15s ofzo dacht ik en ik meen tegenwoordig 5s.

SLOG, transactiegroepen, dat linkt allemaal als writes, maar dat is het probleem hier niet, het gaat naar mijn idee om reads.

Daar komt het vroegere "breathing" ook vandaan. Het syncen van de transactiegroep was de 'load' en het vullen plus wachten op de timeout de 'idle'.

mdadm synced altijd meteen (voor zover ik weet, op wat write caching na, iig geen tijdslimieten).
De bitmap is volgens mij vooral een allocatiefile waar info in staat over welke delen van de array bezet zijn, en is voor zover ik weet fundamenteel anders dan de ZIL.

Writes op mdadm worden gewoon direct doorgevoerd, de bitmap zorgt echter voor consistentie van de array maar bij iedere write I/O moet de bitmap bijgewerkt worden op alle schijven(!) dus de random write performance stort in.

Wat je dus wil om maximale performance er uit te halen, is een tool die 'weet' waar de data staat en alles sequentieel wegschrijft in grote batches. Daardoor verlaag je de track-to-track latency en worden transacties veel sneller gesynced.

Ik denk niet dat ZFS vs MDADM veel uitmaakt qua random write performance. Zeker als SLOG/Bitmap uitstaan doen ze het beiden wel prima.

Dit was het oorspronkelijke probleem / de vraag:

Maar het 'tags lezen' gaat nog erg langzaam. (denk 30 tags per sec)(bij 2 VDEVs).

Of het tags schrijven traag gaat heb ik nog niet gezien.


Om echt conclusies te trekken uit de situatie, is de vraag wat voor soort I/O nu werkelijk naar de storage gaat.

Ik heb zo'n vermoeden dat die files gewoon helemaal in worden gelezen en dan is dan 30 files /s * 15 MB per file is al snel 450 MB/s.

Dit is sowieso al redelijk sequentieel qua I/O en als je dan wat hogere latency en QD hebt, dat zegt misschien niet heel veel.

Nu zat ik leuk iostat syntax te quoten maar onder FreeBSD zal dat wel weer anders zijn. Echter, het aantal reads/s en de bijbehorende average request size (met eventuele latency) zou interessant kunnen zijn.

[ Voor 9% gewijzigd door Q op 17-11-2020 19:36 ]

[FireDrunk]

Hmm, goed punt, mijn verhaal is inderdaad erg Write focussed. Ik kan me even niet meer herinneren of reads wel of niet in de transaction groups zaten, volgens mij niet, maar ik weet ook even niet meer wat de verhouding was qua prioriteit. ZFS heeft hier wel een systeem voor dacht ik, kan het alleen even niet vinden.

Waar ik nog aan zit te denken is of ZFS alle Read IO's zal mergen als ze ver uit elkaar liggen.

Zie deze tunable:
https://manpages.debian.o...dule-parameters.5.en.html

zfs_vdev_read_gap_limit (int)
Aggregate read I/O operations if the gap on-disk between them is within this threshold.

Default value: 32,768.

Als een IO van een disk dus binnen 32K van elkaar valt, gaat ZFS de IO mergen, en het hele block opvragen, ipv de twee losse. Dat scheelt potentieel veel performance, omdat het voor een disk makkelijker kan zijn om 1x32k te lezen, dan bijvoorbeeld 2x512b/4k.

Als je deze waarde groter zet, heb je potentieel meer kans dat je vdev prefetch hits raakt in je tag data. Ik heb geen idee hoe groot deze tag informatie is, maar als deze net iets groter is dan 32k, dan zul je dus altijd per tag, 2 of meer IO's hebben.

Als je deze waarde, samen met de vdev prefetch hoog zet, heb je welliswaar veel meer data om te cachen, maar potentieel meer cache hits.

@Mr.Sun wat @Q zegt is wel belangrijk: een goede blktrace met welke IO Operatie types, en welke request sizes er daadwerkelijk opgevraagd worden, kan behoorlijk uitmaken in het inzicht.

[Q]

Dat verhaal met de reads is zeker ook interessant, en ik weet niet of FreeBSD standaard vanuit het OS ook nog iets met readahead doet...

[Mr.Sun]

OK, tx everybody voor het goede meedenken. Wordt gewaardeerd!

Eerst ff wat nadere info:

1)
Het tags lezen én schrijven gaat beide erg traag en even traag.

2)
(ook niet vreemd want de kern-issue is dus hetzelfde:
- er ontstaat een hoge QD mét bijhorende hoge latency (bij writes nóg hoger: ca 67ms)
- er is sprake van 100% random write cq read
- deze combi is 'de kill', want elke write cq read gaat dus gepaard met die zeg 60ms zoektijd
- na die zeg 60ms zoektijd is er ca 1ms write/read-tijd.... en dit gebeurt dus ca 15 keer per seconde
(want daarna zijn de 1000ms op...).

- op dat punt (na die ca 60ms zoeken) wordt dus het writen/readen gedaan; er vallen dan ca 3 IO's
- 3 x 15 = 45 en dat is ook de IOPS die ik in de Reporting terug kan zien (na read-runs).

Situ tags op file:
- gemiddelde file = zeg 15MB : 15 blocks van 1MB
- op 'de kop' en (helft van de gevallen schat ik) ook op 'de staart' zit een stuk tagsdata
(ik zie dat er 3 IO's vallen en ook dat er bij 1MB blocks 1,5MB in ARC/cache gaat)
- ik meen dat elke write 2 IO's geeft (1 voor de blockpointer en 1 voor de read/write zelf)
(normaliter meen ik 4 IO's per write/read maar de Metadata-VDEV neemt 2 IO's over)(meen ik)
- altijd 2 IO's op kop en helft van de gevallen 2 IO's op staart geeft 3 IO's gemiddeld.


3)
45 IOPS is uiteraard erg weinig.
En ook is duidelijk dat het lezen/schrijven van 15 tags per seconde erg traag is.
Door van 1 naar 2 VDEV's te gaan verdubbelde deze snelheid zich wel (ging naar 30).
Maar als je het vergelijkt met hoe die snelheid is bij - gewoon onder Windows - diezelfde software tags laten lezen bijv:
- vanaf een ouwe 1TB harddisk: 40 tags/sec (50% meer)
- vanaf een single sata-SSDtje: 185 tags/sec (7x meer).
Dan zie je dat we al 3 VDEVs zouden moeten gebruiken, om enkel maar de snelheid van een oud 1TB hard schijffie te halen...

Dus: daarmee 'doorschalen' is niet reeel (je moet naar veel mirrors (12 of zo) maar dan is de redundancy dus ook niet safe... dus je zou dan naar dubbele mirrors moeten... gegeven het datavolume wat er nodig is... moet er dan eerst een XXXXXXXXL Sinterklaasactie komen voor de disks (en de stroomkosten..) ..;-).

Beter gezegd: dus zorgen dat je puur werkt met die tagdata en dan gewoon op SSD is de weg.


4)
Welke data wordt gelezen door tagsoftware:
- Alleen de tagdata wordt gevraagd (en geschreven) door de 'tagsoftware' (diverse pakketten).
- Alleen de blocks met daarop tagdata zie ik in ARC/Cache gaan (dus alleen 1e en laatste block)
- Grootte van de tagsdata achterhaalt: deze is nu ca 400kB per file (dat is nog vrij hoog; gaat naar 100-200kB verwacht ik; 99% van die grootte is een (album cq artist) picto; onderdeel van het collectiewerk is 'uitselecteren beste tags cq resizen picto').

[Mr.Sun]

Transactiegroep vergroten:
- kan best nog helpen, maar vermoed wél bij het hele-files r/w'n , niet bij de tags
- gemiddelde file is dus zeg 15MB en blocks zijn 1MB; runs meestal groot tot zeer groot
- de diskpool draait bij hele-files dus nu op ca 500 MB/s read en 600MB/s write.
(naja en dan kan je gaan rekenen aan die transactiegroep enzo)
- maar ik zal het zeker ook gaan testen ;-) (stond al op m'n lijst)

Dit betreft idd writes.
Maar ik meen ook wel dat 'u oogst wat u zaait'... : ruime batches achter elkaar op de disks planten zal zeker helpen dat de filedata sequentieel geplaatsts wordt en ... bij het readen dan ook meer sequentieel readen bewerkstelligen.


(en dat 'sequencen' is wat je redt naar mijn mening: ook bij hele-files readen/writen is er dus de max latency. En alhoewel stukken minder, is de redding dus om te zorgen dat er zoveel mogelijk blocks achter elkaar, dus zonder latency, geread/write worden.)

[Mr.Sun]

read-gap
(default 32k)

- tagdata is dus nu 400KB (straks zeg 200kB) total
- soms alleen op kop soms ook op staart
- kop ligt vaak aan staart; dan werkt prefetch dus 1 IO
- gemiddelde file = 15MB (15blocks van 1MB)
- dus er zit zeg 13MB tussen kop en staart
- weet niet of die read-gap zinvol is..?

[Mr.Sun]

Dus, even voor

de focus

:

De diskpool wordt:
- een 2x VDEV / Z2 / 6disks (van 8TB elk)
- geeft dus 8x 8TB data-ruimte en dubbele redundancy (en nu nog sparen voor de back-up... ;-)

(Deze pool liep (in 2x 4disk opzet), mét simpel sata-SSD-MetadataVDEVje dus ca 500 read/600 write)
(en dat zal nog wel toenemen na toevoeging disks).


De metadata-VDEV voeg ik later nog toe (of upgrade ik later nog).
Grootte daarvan hangt ff af van of we deze locatie als locatie voor de tagdata gaan gebruiken cq daarvoor een aparte VDEV maken.

Het hele-files lezen heb ik geen zorgen over (dat wordt een kwestie van pool niet laten fragmenteren en af en toe 'defragmenteren' door deze te herschrijven denk ik).

[Mr.Sun]

De vraag is dus hoe het tags lezen/schrijven vlotter te krijgen:

In wezen nu dus '2 wegen naar Rome':

1) Gebruik maken van bestaande 'metadata' (overige tagdata-velden toevoegen)
2) Een filesysteempje laten meelopen dat de tagdata elders cachet

Maar ook is geopperd:

3?) Een database gebruiken (had ik ook al ideeen over en ga ik hierna op in).


De 1e vraag is welke weg kan en welke niet? En welke het makkelijkst te realiseren is?

[ Voor 5% gewijzigd door Mr.Sun op 17-11-2020 22:44 ]

[Mr.Sun]

Re database gebruiken:

@Paul had dit al eerder geopperd (had het wel gezien maar de dag heeft te weinig uren en dit forum geeft teveel food for thought (not) ....;-)

Ik heb eerder ook al met die gedachte gespeeld.
Zelf te weinig ervaring hiermee (tig jaren geleden dat ik iets met dBase deed).
Maar uiteraard past het data/processing-gedrag (ook) goed bij een database.
(queries doen op losse velden ipv hele files r/w'n etc).

Ik had ook al wel gezien dat bijv met 1 van de programma's die ik inzet (nl FooBar2000) je als optie (met een plug-in) ook de tagdata kan wegschrijven naar SQLite.

Maar de hamvraag hier is (denk ik):
- er worden diverse programma's ingezet voor het collectiebewerken (oa MP3Tags, FooBar, Similarity etc)
- de vraag is of deze programma's ook hun tagdata kunnen wegschrijven/ophalen vanuit bijv SQLite
- (en bijv ook of een file manager (als File Explorer) dat ook kan)
- wat ik alleen maar ken is dat deze programma's de tagdata opzoeken op de file-locatie.
- of is het (in FreeNAS/ZFS) te regelen dat die requests dan in de database belanden?

[Q]

Mr.Sun schreef op dinsdag 17 november 2020 @ 21:31:
OK, tx everybody voor het goede meedenken. Wordt gewaardeerd!

Eerst ff wat nadere info:

1)
Het tags lezen én schrijven gaat beide erg traag en even traag.

2)
(ook niet vreemd want de kern-issue is dus hetzelfde:
- er ontstaat een hoge QD mét bijhorende hoge latency (bij writes nóg hoger: ca 67ms)
- er is sprake van 100% random write cq read

Helder en dat komt naar mijn idee gewoon omdat je storage dit niet bij kan benen.

3)
45 IOPS is uiteraard erg weinig.
En ook is duidelijk dat het lezen/schrijven van 15 tags per seconde erg traag is.
Door van 1 naar 2 VDEV's te gaan verdubbelde deze snelheid zich wel (ging naar 30).
Maar als je het vergelijkt met hoe die snelheid is bij - gewoon onder Windows - diezelfde software tags laten lezen bijv:
- vanaf een ouwe 1TB harddisk: 40 tags/sec (50% meer)
- vanaf een single sata-SSDtje: 185 tags/sec (7x meer).
Dan zie je dat we al 3 VDEVs zouden moeten gebruiken, om enkel maar de snelheid van een oud 1TB hard schijffie te halen...

- Het is goed mogelijk dat dit puur komt door de netwerk overhead, mogelijk van SMB zelf?
- Het kan specifiek liggen aan FreeBSD
- Het kan specifiek liggen aan ZFS
- Het kan nog een andere oorzaak hebben
- Hoe is er met die 1TB gebenchmarked....

Dus: daarmee 'doorschalen' is niet reeel (je moet naar veel mirrors (12 of zo) maar dan is de redundancy dus ook niet safe... dus je zou dan naar dubbele mirrors moeten... gegeven het datavolume wat er nodig is... moet er dan eerst een XXXXXXXXL Sinterklaasactie komen voor de disks (en de stroomkosten..) ..;-).

Even advocaat van de duivel: heb je dan wel een business case als dit soort investeringen niet mogelijk zijn?

Hoef je niet hier publiek te beantwoorden, maar voor jezelf even goed nagaan. Je hebt al enorm veel tijd in dit verhaal gestoken. Die tijd moet ook wat waard zijn.

Beter gezegd: dus zorgen dat je puur werkt met die tagdata en dan gewoon op SSD is de weg.

Dat klinkt als een database. SSD is prima, maar waarschijnlijk niet eens het grootste punt.

4)
Welke data wordt gelezen door tagsoftware:
- Alleen de tagdata wordt gevraagd (en geschreven) door de 'tagsoftware' (diverse pakketten).
- Alleen de blocks met daarop tagdata zie ik in ARC/Cache gaan (dus alleen 1e en laatste block)
- Grootte van de tagsdata achterhaalt: deze is nu ca 400kB per file (dat is nog vrij hoog; gaat naar 100-200kB verwacht ik; 99% van die grootte is een (album cq artist) picto; onderdeel van het collectiewerk is 'uitselecteren beste tags cq resizen picto').

Als ik die 400kB per file pak en dat vermenigvuldig met 6 miljoen files dan zit ik nog op 2.4 TB. Dat gaat wel passen op een wat duurdere SSD.

Het probleem wat je in mijn ogen nu hebt is dat al die diverse pakketten aan tagsoftware op de muziek files zelf opereren en waarschijnlijk niet op de data in een database. Dat zou betekenen dat je een volledig end-to-end custom stuk software moet gaan schrijven (of laten schrijven) om alles te doen wat die pakketten doen, maar dan met een database als tussenlaag.

Dat klinkt als ongeveer 1000x duurder dan gewoon een shit-load aan schijven te kopen.
Dat klinkt als ongeveer 1000x duurder dan echt een keer RAID6 te testen met Linux en MDADM (schrijven zal 1/6 deel performance zijn van lezen)
Dat klinkt als ongeveer 1000x duurder dan een keer RAID10 te testen met Linux en MDADM (schrijven is 50% van lezen)
Dat klinkt als ongeveer 100x duurder dan gewoon 50+TB aan SSDs te kopen en daar de muziek op te zetten (test wel of het helpt van te voren --> of SSDs uitmaken in de FreeBSD machine, klinkt stom maar dit is een dure misser als het niet helpt)

Een mooi plaatje is misschien wel een Linux doos met iSCSI + MDADM array, Windows doet prima iSCSI en dat protocol heeft weinig latency. SMB 3.0 met RDMA is ook tof, maar zie dat maar goed aan de praat te krijgen. iSCSI lijkt makkelijker.

Nog gekker: gooi Windows op die NAS, gebruik storage spaces (mirror) of een hardware RAID kaart en export dit volume als iSCSI. Kan ook.

Laatste vraag: heb je enig idee hoe andere partijen met dit soort werk omgaan en wat zij doen? Misschien dat je daar inspiratie uit kunt halen.

That's it.

---

[Mr.Sun]

Alle opzetjes gebaseerd op harddisks, blijven uiteraard kampen met het 'killing' feit dat harddisks extreem hoge latency geven.
Bij 100% random writes/reads (=vast gegeven bij tags) maakt dat de disks bijzonder lage r/w-speed leveren.

Je krijgt (misschien) een beetje minder overhead etc bij Linux of Windows vs ZFS, en daardoor iets meer speed, of misschien ook niet; maar het blijft altijd 'werken met bijzonder lage startperformance'.
(bij het direct gebruiken van een ouwe harddisk heb je denk ik ongeveer de meest overheadloze situatie en dan kom je nog niet verder dan max 35-40 tags/sec)(vs simpel sata-SSD'tje 185).
(in een situatie waarin er wat voor vorm van redundancy dan ook zit (ZFS's Z1/2 of Linux/Windows Raid6/10) gaat dit altijd ver, ver onder die 35-40 per VDEV scoren en blijf je terugkomen op
"megagrote harddiskbak vormen" enkel vanwege nog geen TB aan tagsdata (3mio files x 200kB = 600GB).

Dus logica is: richten op oplossingen waarbij je de tags gewoon op SSD hebt.
(grove, sequentiele data op de diskpool; andere op SSD)

[Mr.Sun]

Mogelijke invullingen hiervoor dus:

1) Database gebruiken:

@Paul Kan jij misschien ff reageren op de bruikbaarheid van het toepassen van een (SQLite) database hier?
- Ik had al aangegeven dat bijv FooBar al werkt hiermee. Ik ken de ontwikkelaars van de belangrijkste 2 overige pakketten ook wel; zal wel ff checken of dat werkt met bijv sqlite.
- Maar stel (zoals bij FooBar) dat die pakketten met SQLite werken; hoe zetten we dat op, op de FreeNAS/ZFS-bak?

2) Gebruikmaken van ZFS-metadata:

Ik zag het voortborduren op en gewoon gebruikmaken van het bestaande ZFS-metadata systeem ook als eenvoudige oplossing.
- De 'basis file-datavelden' (alle ook 'Tags') zitten er immers al in; hier moeten alleen wat 'overige file-datavelden' ook toegevoegd
- Wie heeft inzicht in ZFS-metadata en of we hier velden aan kunnen toevoegen? (of: wie weet iemand die dat heeft?)


3) Tagdata-caching regelen via een meelopend filesysteempje.

De 3e mogelijkheid is dus om een filesysteempje te laten meelopen dat de tags cachet.
- Zoals @Thralas aangaf, moet hier dan (op basis van 'splitfs' of soortgelijk stukje code) "op een regenachtige zondagmiddag' wat in elkaar gestoeid" ;-)
- Nadere ideeen of meer inzichten hierbij?

Time for bed (vierkante ogen... ;-)

[Q]

@Mr.Sun Veel software heeft een API of SDK of een ander type interface waarmee je de GUI omzeilt en gewoon vanuit software rechtstreeks de data kan queryen en kan manipuleren.

Als je kijkt naar FooBar --> Is dat FooBar2000? Dan zie je dat die bijvoorbeeld een SDK biedt. https://www.foobar2000.org/SDK

Het enige stukje software wat jij dan nodig hebt is iets dat mutaties in de files in de database update en vice versa.

De files inlezen updaten kan dan 's Nachts lopen stampen, of in de achtergrond, batch-gewijs.

Dan is de performance van de schijven niet meer zo'n probleem.

[Paul]

Mr.Sun schreef op woensdag 18 november 2020 @ 03:09:
@Paul Kan jij misschien ff reageren op de bruikbaarheid van het toepassen van een (SQLite) database hier?
- Ik had al aangegeven dat bijv FooBar al werkt hiermee. Ik ken de ontwikkelaars van de belangrijkste 2 overige pakketten ook wel; zal wel ff checken of dat werkt met bijv sqlite.
- Maar stel (zoals bij FooBar) dat die pakketten met SQLite werken; hoe zetten we dat op, op de FreeNAS/ZFS-bak?

Of je een database kan gebruiken hangt 100% af van welke software je gebruikt / wat je nu precies wil doen. En of het zin heeft hangt ook af van hoe vaak je dit wil doen; als het om één run gaat (als je de muziek eenmaal van een tag hebt voorzien dan staan ze er...) dan had je die run vorige week aan kunnen zetten en was het nu ongeveer klaar geweest

De database zelf hoeft niet per se op ZFS, al kan dat wel. Als de database-software op BSD of Linux gebruikt dan kan dat direct, maar je kunt altijd iets via iSCSI, NFS of SMB aanbieden aan een andere machine.

[Mr.Sun]

Tx voor de goeie input.

Ff druk met oa testen.

Kom er in het weekend op terug.

[Tha_Butcha]

Ik heb een ZFS array bestaande uit 2 vdevs:

- 4 * 3TB RAIDZ-1
- 4 * 8TB RAIDZ-1 (later toegevoegd)

Controller is een IBM M015 in IT mode

Nu was een van de schijven uit de eerste vdev errors aan het geven en aangezien ik toch aan het upgraden was (naar een degelijke 2U kast) en toch al mijn vdevs wilde groeien, heb ik een nieuwe lading 8TB hds besteld.

Ik heb deed het volgende om de defecte HD te vervangen:

code:

sudo zpool replace -f pool0 /dev/sdc /dev/disk/by-id/wwn-0x5000cca0becc5d58

Allemaal prima, resilver zou zo'n 5 dagen duren (lijkt me veel, maar goed)

Echter nu kijk ik, en beginnen ook de andere disks error te vertonen en besluit zfs ook gelijk maar die disks te resilveren.

code:

  pool: pool0
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sat Nov 21 16:06:00 2020
        505G scanned at 11.7M/s, 394G issued at 9.13M/s, 32.0T total
        125G resilvered, 1.20% done, no estimated completion time
config:

        NAME                          STATE     READ WRITE CKSUM
        pool0                         DEGRADED     0     0     0
          raidz1-0                    DEGRADED     0     0     0
            replacing-0               DEGRADED     0     0 3.21M
              11378620474646499974    UNAVAIL      0     0     0  was /dev/sdc
              wwn-0x5000cca0becc5d58  ONLINE       0     0     0  (resilvering)
            6509094044150173773       UNAVAIL      0     0     0  was /dev/sdi
            sdb                       DEGRADED     0     0 3.21M  too many errors  (resilvering)
            sda                       DEGRADED     0     0 3.09M  too many errors  (resilvering)
          raidz1-1                    DEGRADED     0     0     0
            wwn-0x5000cca252e65eef    FAULTED      0     3     0  too many errors
            wwn-0x5000cca252e6b9a7    ONLINE       0     0     0
            wwn-0x5000cca252e660f6    ONLINE       0     0     0
            scsi-35000cca27dc49689    ONLINE       0     0     0

De tijd is dus zo erg, dat er niet eens een estimation wordt gegeven (een keer keek ik eerder en was het opgelopen naar 30 dagen).

Vraag is: wat kan ik nu het beste doen zodat het zo snel mogelijk gefixed is en hopelijk geen dataverlies?

_{Dit is een plex fileserver, belangrijke data staat elders (321 methode), dus dataverlies is niet einde van de wereld, wel klote om opnieuw te verzamelen}

[Q]

@Tha_Butcha Ik zou eerst eens beginnen bij het begin en kijken wat er precies aan de hand is. Stap 1: kijk eens in /var/log/syslog of messages en zoek naar Kernel errors over de schijven. grep op de schijf namen.

Je hebt op dit moment ook zoveel schijven over de VDEVs heen die gek doen, hoe heb je de schijf vervangen: heb je hot swap bays, had je de machine aan staan of niet, kan het zijn dat je tegen kabels bent aan gegaan?

En heb je ECC geheugen of niet? (rot non-ecc geheugen kan ook voor chksum errors zorgen, maar die zie je dan meestal over veel meer schijven)

[Mr.Sun]

@Paul en @Q en de anderen: dit weekend nog weer getest:

eerst ff recap van bevindingen tot nu toe:

Dit gaat dus om een vrij grote media-pool op FreeNAS/ZFS.
- FreeNAS v 12
- Pool 2 VDEVs / 2x 6disks van 8TB
- MetaData VDEV (2x500GB sata-SSD)(mirror)
.
- meeste files zijn ca 10MB of ca 35MB
- frequent grote runs files schrijven en lezen (van/naar/op pool)
- frequent grote runs 'tagdata' schrijven en lezen
.
- geen 'frequently used' pakket aan files; dus ARC/file-cache geen functie.
- files r/w rechtstreeks door diskpool gaat vrij goed (met allerlei truuks, later meer daarover)
- tags r/w gaat knudde (erg langzaam)
- tags r/w verbeteren is dus topic van deze thread.

We hadden al wel vastgesteld dat 'de kill' zit in het feit dat:
1) het 'tags' lezen/schrijven dus 100% random r/w is (dwz: elke r/w krijgt de volle latency).
2) die latency is erg hoog, want de QD gaat altijd naar max dus latency is ook max...
('hoge latency' is zo'n fraai eufemistisch anglicisme waarmee feitelijk bedoeld wordt dat de diskpool dus bij elke r/w heel veel tijd nodig heeft om de lees/schrijfkoppen te verplaatsen... zodanig veel dat het bijna heel de tijd daaraan kwijt raakt)("60 ms latency en dan 1 ms r/w"...etc ).

Ik heb als eerste hier aangekaart of we die QD en dus de latency niet konden beteugelen.
Maar dat werd niet als zinvol gezien en bij het testen van diverse tunables was er nul effect (vreemd want die tunables uit de ZFS tuningguide lijken daarvoor te zijn, maar na zoveel testen en nul effect heb ik dat terzijde gelegd).

Bovendien is het veel passender en logischer om dit soort data en dit soort processing vanaf SSD te doen.

Testen van tags lezen bij diverse dragers

Ik heb dit weekend oa een reeks testen gedaan waarin dit ook goed tot uitdrukking komt:


Kijk er maar's naar.
Eerste conclusie is dat dat bij gebruik SSD in ieder geval die ca 116 files/sec te verwachten is (zoals in dit schema ook bij r/w van tagdata vanaf ARC/filecache).
Daar gaat dus nog heel veel verloren in overhead....
Maar dat is dan dus ruim factor 4x sneller, als het werken met 2x VDEV in harddisks.
Met die ca 116 files/sec heb je al wel "zo ongeveer' een werkbare snelheid.

Maar.... is er ook extra snelheid te verwachten doordat de tagdata nu ook deels sequentieel zal lezen/schrijven (op de SSD-locatie staat enkel de tagdata, en block-aan-block)(vs nu elk tag-block ver apart van hetvolgende).

En... uiteraard als je de tags niet onder ZFS/FreeNAS plaatst...(zie schema boven).
Ook die laatste versnellingen zal denk ik iets van 3-4x meer speed opbrengen (zie max in het schema).

Dus: logica om middels tags op SSD te werken is duidelijk ..


3 mogelijkheden om dat te regelen

We hebben een aantal methodes om met 'puur de tags op SSD' te kunnen werken aangekaart:
1)
De bestaande ZFS 'metadata' completeren met deze tagdata (daarvoor moeten we regelen dat er een aantal velden toegevoegd kunnen worden aan de ZFS-metadata)
2)
Filesysteempje laten meelopen dat de tagdata continue cachet (op SSD locatie) (daarvoor moet het dan een zondagmiddag regenen)
3)
Database gebruiken; centrale locatie waarnaartoe de div software schrijft/leest (obv SQLite oid opzetten).

Hieronder ga ik ff op deze 3 mogelijke oplossingen in.

[Mr.Sun]

Re 1)
De bestaande ZFS 'metadata' completeren met deze tagdata.

Hiervoor moeten we regelen dat er een aantal velden toegevoegd kunnen worden aan de ZFS-metadata:

- hierin zijn nu al opgenomen de 'basis' filedata, als 'filenaam', 'filesize' etc
- een aantal overige filedata-velden (als 'naam artiest' etc) moet dus toegevoegd kunnen worden
- dan is het ook compleet opgelost: want de 'handling' van de metadata is al compleet geregeld onder FreeNAS/ZFS (ie hoe je metadata middels ARC/L2ARC cq MetadataVDEV/special class handled)

>> Wie heeft er inzicht in het gebruiken/uitbreiden van deze metadata?
(of weet iemand die het wél heeft?).

[Mr.Sun]

Re 2)
Filesysteempje laten meelopen dat de tagdata continue cachet (op SSD locatie).

Hiervoor moet het dan "een zondagmiddag regenen "..

Ik weet niet hoe lastig dit is (mijn eigen programmeerwerk is tig jaar geleden).
Misschien kan @Thralas iets hierover aangeven?
(je verwees al wel netjes naar die 'fssplit' code dus er is al wel een begin..?).

Of zijn 1) of 3) makkelijker te realiseren?

[Mr.Sun]

Re 3)
Database gebruiken; centrale locatie waarnaartoe de div software schrijft/leest (obv SQLite oid opzetten).

@Paul Je vroeg nog konkreet naar welke software en wat dan de (processing) actie is.

Hoofdpakketten zijn het genoemde MP3Tag, FooBar en Similarity.
Middels al deze pakketten worden er (handmatig en softwarematig) tags gelezen en herschreven/aangepast.
Niet tegelijk maar in stappen na elkaar.
Het 'cultiveren' van de totaalcollectie cq het toevoegen/opnemen van een nieuwe filebatch gebeurt steeds in een serie van (handmatige cq automatische) werkstappen waarbij er bij elke stap tags worden gelezen en herschreven/aangepast.

Oa worden er bijv steeds kruisvergelijkingen gedaan tussen nieuwe filebatches en bestaande collectie, gericht op de compleetheid van de tagdata. Sets met meest complete tagdata (van uiteraard dezelfde muzieknummers) worden uitgeselecteerd en 'best of crop' wordt geschreven naar alle zelfde muzieknummers).

Kern is dus dat er met elk pakket steeds maar weer tags worden gelezen en herschreven/aangepast.
(de totaalcollectie/audiofiles verandert dus doordat de tagdata steeds verandert en ook doordat er files gedelete worden (dubbelen, low soundquality etc etc).
(op een gegeven moment zullen er weinig nieuwe filebatches meer zijn; en is de collectie ook zo goed als 'uitgerijpt')
(Dus....om je vraag te beantwoorden... : "nee, dat is niet een kwestie van vorige week aanzetten en dan is het morgen misschien al wel klaar") (veel runs dus, intensief werk en zeker nodig dat het tags lezen/schrijven een aantal keren vlotter gaat als nu...).

Wat nodig is dat middelgrote runs van zeg 50.000 files/tagjes bijwerken 'past binnen het werkproces' (dus niet een half uur wachten...). En dat grote runs van zeg 1 mio files/tags niet gelijk maakt dat je die dag niet verder kunt. Dat gaat dus niet bij zeg 25 tags/sec maar wel bij zeg 150-200 tags/sec.


Je besprak oa de locatie van de database.
Onder FreeNAS/ZFS is er altijd de extra overhead (van oa Samba etc).

(je ziet in het schema hierboven dat onder Windows er een factor 3-4x sneller tags gelezen wordt (software op dat Workstation leest van SSD/disk op dat Workstation) als wanneer software van de NAS (>Samba>ZFS) leest (zelfs als het gaat om van ARC lezen 2-4x sneller).

Dus idealiter staat de database op het Workstation (met daarop Windows).


Dus ik stel me even hardop voor hoe dat ik denk dat dat loopt:
- Op het Workstation staat dus een centrale database (QLite ofzo?)
- Bij het opslaan van nieuwe files worden de tags daarvan in de database geladen/toegevoegd?
- Softwarepakketten waarmee de collectie verbeterd wordt, lezen daaruit de tags en schrijven er correcties naar toe? (elk pakket moet dan met (bijv) sqlite kunnen werken)(ik check dat nog)(FooBar kent dus oa een plug-in daarvoor)
- De database schrijft continue de tag-wijzigingen door naar de audiofiles op de NAS/diskpool? (de NAS-pool staat dus via Samba/SMB op een netwerkmap op het Workstation; daar schrijft de database naartoe?)
(PS: dit ijlt bij grote runs dus een stukkie na?)(aandachtspunt om niet gelijk erna de files te raadplegen met andere software cq files over te zetten).

Sorrie voor de lap tekst...

Waar ik "? " heb gezet is het een vraag...

Alvast dank voor de reactie.

(Paul maar uiteraard ook anderen die ervaring hebben met werken met een database)

[Paul]

Mr.Sun schreef op dinsdag 24 november 2020 @ 01:52:
die latency is erg hoog, want de QD gaat altijd naar max dus latency is ook max...

Stel, je doet een aantal requests. Specifiek, je volgende request komt voordat je vorige is afgehandeld. Laten we voor het gemak 10ms aanhouden voor het afhandelen van een request op een HDD. Als je in één keer 10 requests doet, dan heb je een queue van 10 diep. Het antwoord op het eerste request doet er 10ms over, het antwoord op het tweede request komt pas na 20ms, na 30ms heb je het antwoord op het derde request, en het 10e is er pas na 100ms. Je 10 requests doen er samen 550ms over, voor een gemiddelde latency van 55ms.

De maximale queue depth (limiet / instelling) is niet hetgeen dat voor de latency zorgt, de requests die je doet en de tijd die het kost dat af te handelen zorgen daar voor. De maximale QD is voor een soort verwachtingsmanagement

Re 3)

Ik ken die pakketten niet, dus ik weet niet wat ze met een database doen of kunnen

Stappen zijn:
1) Data exporteren naar database
1a) Nieuwe data ook exporteren naar database
2) Data aanpassen in de database ipv in de files
3) Optioneel: Gewijzigde data weer naar file schrijven

MP3 tags uitlezen en in een database stoppen (en de andere kant op weer terug, dus stap 1, 1a en 3) is wel te scripten (ik twijfelde vooral over het uitlezen, maar Google to the rescue, dit is de 1e hit: https://stackoverflow.com...le-metadata-in-powershell).

Je kunt stap 3 ook continue (zeker als je handmatig aan het bewerken bent) maar dan moet je in de database een trigger hebben zodra er iets gewijzigd wordt dat dit het script aanroept om dit naar het bestand te schrijven.

- Op het Workstation staat dus een centrale database (QLite ofzo?)

Die database draait *ergens*. Met een normaal LAN ertussen maakt het niet bijzonder veel uit of dit lokaal of over het netwerk gaat. Je kunt de database beter dichter op de snelle storage hebben dan dichter bij je software, maar een SSD in je Windows-machine en daar de DB op is natuurlijk het snelst. Welke database dit moet zijn hangt af van waar je software mee overweg kan.

- Bij het opslaan van nieuwe files worden de tags daarvan in de database geladen/toegevoegd?

Yup, stap 1a hierboven

- Softwarepakketten waarmee de collectie verbeterd wordt, lezen daaruit de tags en schrijven er correcties naar toe? (elk pakket moet dan met (bijv) sqlite kunnen werken)(ik check dat nog)(FooBar kent dus oa een plug-in daarvoor)

Precies.

- De database schrijft continue de tag-wijzigingen door naar de audiofiles op de NAS/diskpool?
(de NAS-pool staat dus via Samba/SMB op een netwerkmap op het Workstation; daar schrijft de database naartoe?)

Nee, de database-software schrijft de tag-wijzigingen naar de database. Deze wijzigingen weer toepassen op de media moet je zelf doen, net als dat je het importeren zelf hebt moeten doen.

[Mr.Sun]

@Paul ea.

Bedankt nog voor de input.
Ben nu vooral bezig met de makers van die paar softwarepakketten. Om te bezien hoe elk pakket kan werken met SQLite of een ander database-programma.


1)
Ofwel die programma's moeten dus elk direct kunnen schrijven naar en lezen van de database.
(je trekt een folder erin (lezen) of je slaat een aangepaste batch met tags op (schrijven).

2)
Danwel we zorgen voor een syncing (middels script) tussen de dedicated libraries van die diverse pakketten en de database.
(en daarnaast dus voor syncing tussen database en media-files on diskpool)

PS:
(voor dat laatste al wel een script gevonden)(meen ik..?)
https://www.npmjs.com/package/sync-music-db
Of is dit niet wat jij bedoelde?


Het werken met een database is de meest zuivere en snelle methode om de tagdata te handlen.
Het geeft je ook de vrijheid om de FreeNAS/ZFS optimaal te tunen voor 'gewoon files lezen/schrijven'.

[HyperBart]

Met black friday 6 x WD 12TB op de kop kunnen tikken voor 1126 EUR .

Binnenkort shucken maar eerst eens kijken hoe ze werken icm ZFS en USB3.1.

[RobertMe]

HyperBart schreef op zaterdag 28 november 2020 @ 13:44:
Met black friday 6 x WD 12TB op de kop kunnen tikken voor 1126 EUR .

Binnenkort shucken maar eerst eens kijken hoe ze werken icm ZFS en USB3.1.

Let op, je kunt deze schijven niet gebruiken, shucken, en weer verder gebruiken. De USB - SATA controller snoept een aantal sectoren op. Dus na shucken moet je ze opnieuw formatteren.

[HyperBart]

RobertMe schreef op zaterdag 28 november 2020 @ 13:49:
[...]

Let op, je kunt deze schijven niet gebruiken, shucken, en weer verder gebruiken. De USB - SATA controller snoept een aantal sectoren op. Dus na shucken moet je ze opnieuw formatteren.

Aha, da’s een fijne tip. Niet een op een overneembaar dus. Ook niet als je de partities kleiner maakt?

[RobertMe]

HyperBart schreef op zaterdag 28 november 2020 @ 16:20:
[...]

Aha, da’s een fijne tip. Niet een op een overneembaar dus. Ook niet als je de partities kleiner maakt?

Poe, dat durf ik niet met zekerheid te zeggen. Maar ik meen ook iets begrepen te hebben dat de partitietabel voor en achteraan wordt opgeslagen. Als je de HDD uit de behuizing haalt is achteraan dus een andere plek en dus lijkt mij dat dat problemen. En in die zin niet zo zeer de partities inhoudelijk / het filesystem. Lijkt mij dat de partitietabel niet meer gelezen kan worden en daardoor de hele schijf "onleesbaar" is.

Maar wat ik mij nu zo bedenk, wellicht is het wel mogelijk dat je na het shucken een nieuwe partitietabel aanmaakt die exact hetzelfde is (dus identieke begin en eind sectoren). Gezien de HDD na shucken groter is zou het gebruik van die sectoren dus geen issue hoeven te zijn (en zou je er op het eind een aantal over houden). Mogelijk dat bv ZFS (of welk filesystem dan ook) daarna de filesystem table en ook de data weer gewoon kan lezen. Maar dat zou je dan echt even moeten proberen en is puur een theorietje wat ik mij nu bedenk.

[Q]

HyperBart schreef op zaterdag 28 november 2020 @ 13:44:
Met black friday 6 x WD 12TB op de kop kunnen tikken voor 1126 EUR .

Binnenkort shucken maar eerst eens kijken hoe ze werken icm ZFS en USB3.1.

Tenzij je die schijven over meerdere USB3 controllers verdeelt zal een rebuild of scrub tergend langzaam gaan

[rikadoo]

@RobertMe wat bedoel je precies? Ik heb mijn 5x 8TB disken ook gewoon na het shucken ingezet en ik kon deze gewoon prima gebruiken...

[RobertMe]

rikadoo schreef op zaterdag 28 november 2020 @ 17:31:
@RobertMe wat bedoel je precies? Ik heb mijn 5x 8TB disken ook gewoon na het shucken ingezet en ik kon deze gewoon prima gebruiken...

Na shucken moet je bij mijn weten de HDD opnieuw partitioneren. Dit omdat de USB - SATA controller van de MyBook / Elements bij mijn weten minder sectoren rapporteert dan de disk daadwerkelijk heeft. Dus voorbeeld: disk heeft 100 sectoren, via USB worden er maar 95 gerapporteerd. Als je de HDD partitioneert komt de partitietabel bv in sectoren 1-3 en de kopie / backup in 93-95. Vervolgens shuck je de HDD, waarna het OS wel t/m sector 100 ziet. Het OS wil dan dus de partitietabel lezen van sector 1-3 (gaat goed) en 98-100. En dat laatste gaat dus mis, want daar staat geen partitietabel.

Als je de HDD dus opnieuw partitioneert na shucken is er verder ook niks aan de hand. Want dan komt de tabel gewoon op 1-3 en 98-100 te staan. Stop je hem daarna weer in behuizing dan gaat het dus weer mis omdat de backup partitietabel niet gelezen kan worden.

[HyperBart]

Q schreef op zaterdag 28 november 2020 @ 17:19:
[...]


Tenzij je die schijven over meerdere USB3 controllers verdeelt zal een rebuild of scrub tergend langzaam gaan

@Q kan je wat uitweiden? Want ik zie niet onmiddellijk waarom? Een USB3.1 controller biedt toch 10Gbps (Gbit), met 1GB/s verdeeld over 6 schijven kan ik ergens denken dat het wel trager gaat maar niet tergend traag mits UAS gebruikt wordt?

[HyperBart]

Voor de mede ZFS gebruikers had ik nog wel een interessante site gevonden om disk prijzen te vergelijken:

https://diskprices.com/
Al dan niet in combinatie met camelcamelcamel kan je goed analyseren of je een goede deal doet. Op BF stond er dus een 12TB WD externe HDD geprijsd aan 179.99. Wat ze er dan wel niet bijzeggen is dat het geldt op 1 exemplaar. Dat verklaart de prijs die hoger ligt voor mijn 6 exemplaren.

Als je dan gaat kijken in V&A dan lopen de prijzen daar aardig op.

Ik heb spijt dat ik er niet 10 of 20 besteld heb en ze in V&A heb gegooid tegen een democratische prijs want het zijn geen SMR schijven.

[rikadoo]

RobertMe schreef op zaterdag 28 november 2020 @ 17:55:
[...]

Na shucken moet je bij mijn weten de HDD opnieuw partitioneren. Dit omdat de USB - SATA controller van de MyBook / Elements bij mijn weten minder sectoren rapporteert dan de disk daadwerkelijk heeft. Dus voorbeeld: disk heeft 100 sectoren, via USB worden er maar 95 gerapporteerd. Als je de HDD partitioneert komt de partitietabel bv in sectoren 1-3 en de kopie / backup in 93-95. Vervolgens shuck je de HDD, waarna het OS wel t/m sector 100 ziet. Het OS wil dan dus de partitietabel lezen van sector 1-3 (gaat goed) en 98-100. En dat laatste gaat dus mis, want daar staat geen partitietabel.

Als je de HDD dus opnieuw partitioneert na shucken is er verder ook niks aan de hand. Want dan komt de tabel gewoon op 1-3 en 98-100 te staan. Stop je hem daarna weer in behuizing dan gaat het dus weer mis omdat de backup partitietabel niet gelezen kan worden.

Aah ja oke, nou ik heb ze in een tussentijd nog even als test gebruik in xpenology en in truenas. Dus lijkt me wat ze wel opnieuw gepartitioneerd zijn. Momenteel zitten ze allemaal in een Truenas systeem maar bij het aanmaken van een pool worden de disken ook geformatteerd toch?

[Brahiewahiewa]

rikadoo schreef op zaterdag 28 november 2020 @ 18:42:
[...] bij het aanmaken van een pool worden de disken ook geformatteerd toch?

Ja, maar formatteren is wat anders als partitioneren

[Q]

HyperBart schreef op zaterdag 28 november 2020 @ 18:26:
[...]

@Q kan je wat uitweiden? Want ik zie niet onmiddellijk waarom? Een USB3.1 controller biedt toch 10Gbps (Gbit), met 1GB/s verdeeld over 6 schijven kan ik ergens denken dat het wel trager gaat maar niet tergend traag mits UAS gebruikt wordt?

Als jij werkelijk een USB3.1 10Gbps controller hebt, dan heb je waarschijnlijk gelijk en zit ik er naast. Ik ben benieuwd.

[FireDrunk]

OpenZFS 2.0 is gereleased!
https://github.com/openzfs/zfs/releases/tag/zfs-2.0.0

In deze release is de codebase voor BSD en Linux samengevoegd.

En een paar leuke nieuwe major functies:

Sequential resilver - The sequential resilver feature can rebuild a failed mirror vdev in a fraction of the time it would take a traditional healing resilver. Full redundancy is restored as quickly as possible and then the pool is automatically scrubbed to verify all of the data checksums. #10349

Persistent L2ARC - This feature makes the L2ARC cache device persistent across reboots thereby eliminating the usual cache warmup time normally needed after importing your pool. #9582

ZStandard compression - ZStandard is a modern, high performance, general compression algorithm which provides similar or better compression levels to GZIP, but with much better performance. ZStandard provides a large selection of compression levels to allow a storage administrator to select the preferred performance/compression trade-off. #10278

Redacted zfs send/receive - Redacted streams allow users to send subsets of their data to a target system. This allows users to save space by not replicating unimportant data within a given dataset or to selectively exclude sensitive information. #7958

En diverse andere kleine dingen, maar staan ook wel op de pagina.

[RobertMe]

Ik heb momenteel een RAIDZ1 array van 3 8TB schijven. Met Black Friday heb ik nu een mooie 14TB schijf gescoord en ik wil één van de bestaande schijven met deze vervangen. Ik weet dat dit qua capaciteit niet uit maakt totdat ze allemaal vervangen zijn. Initieel wil ik de schijf echter "erbij" plaatsen en dan later de oude verwijderen.

Als ik het goed heb kan ik daarvoor deze commando's gebruiken?

zpool attach tank <id huidige schijf> <id nieuwe schijf>

zpool detach tank <id huidige schijf>

Correct?

Eerst maak ik dan een mirror van een huidige schijf met de nieuwe, en na verloop gooi ik de huidige dan eruit. Wat in theorie dan gelijk zou zijn aan een zpool replace alleen dan "vertraagd" verwijderen.

[CurlyMo]

RobertMe schreef op donderdag 3 december 2020 @ 18:22:
Ik heb momenteel een RAIDZ1 array van 3 8TB schijven. Met Black Friday heb ik nu een mooie 14TB schijf gescoord en ik wil één van de bestaande schijven met deze vervangen. Ik weet dat dit qua capaciteit niet uit maakt totdat ze allemaal vervangen zijn. Initieel wil ik de schijf echter "erbij" plaatsen en dan later de oude verwijderen.

Wat jij wil gaat niet zo.

Als ik het goed heb kan ik daarvoor deze commando's gebruiken?

zpool attach tank <id huidige schijf> <id nieuwe schijf>

zpool detach tank <id huidige schijf>

Correct?

Nee dus.

Ik zou je adviseren gewoon eens een test pool aan te maken met bestanden en dan daarop te kijken hoe je het beste je doel bereikt:

root@pve:/# truncate -s 100MB /tmp/a
root@pve:/# truncate -s 100MB /tmp/b
root@pve:/# truncate -s 100MB /tmp/c
root@pve:/# zpool create foo raidz1  /tmp/a /tmp/b /tmp/c
root@pve:/# zpool status foo
  pool: foo
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        foo         ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            /tmp/a  ONLINE       0     0     0
            /tmp/b  ONLINE       0     0     0
            /tmp/c  ONLINE       0     0     0

errors: No known data errors

[RobertMe]

CurlyMo schreef op donderdag 3 december 2020 @ 18:30:
[...]

Wat jij wil gaat niet zo.


[...]

Nee dus.

Ik zou je adviseren gewoon eens een test pool aan te maken met bestanden en dan daarop te kijken hoe je het beste je doel bereikt:

root@pve:/# truncate -s 100MB /tmp/a
root@pve:/# truncate -s 100MB /tmp/b
root@pve:/# truncate -s 100MB /tmp/c
root@pve:/# zpool create foo raidz1  /tmp/a /tmp/b /tmp/c
root@pve:/# zpool status foo
  pool: foo
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        foo         ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            /tmp/a  ONLINE       0     0     0
            /tmp/b  ONLINE       0     0     0
            /tmp/c  ONLINE       0     0     0

errors: No known data errors

Ik zie het, attachen kan alleen tegen mirrors en top level disks. Oftewel: wat ik wil gaat niet, en de enige optie is gewoon direct een replace te doen (en dus ook er vanuit gaan dat de nieuwe schijf goed werkt en als die alsnog kuren geeft dan maar weer terug vallen op de oude om snel het raidz array te rebuilden / resilveren voordat evt. 2 drives falen). Correct?

[CurlyMo]

RobertMe schreef op donderdag 3 december 2020 @ 19:20:
[...]

Ik zie het, attachen kan alleen tegen mirrors en top level disks. Oftewel: wat ik wil gaat niet, en de enige optie is gewoon direct een replace te doen (en dus ook er vanuit gaan dat de nieuwe schijf goed werkt en als die alsnog kuren geeft dan maar weer terug vallen op de oude om snel het raidz array te rebuilden / resilveren voordat evt. 2 drives falen). Correct?

Klopt, dat is de enige manier voor jouw doel.

[RobertMe]

RobertMe schreef op zaterdag 28 november 2020 @ 17:55:
[...]

Na shucken moet je bij mijn weten de HDD opnieuw partitioneren. Dit omdat de USB - SATA controller van de MyBook / Elements bij mijn weten minder sectoren rapporteert dan de disk daadwerkelijk heeft. Dus voorbeeld: disk heeft 100 sectoren, via USB worden er maar 95 gerapporteerd. Als je de HDD partitioneert komt de partitietabel bv in sectoren 1-3 en de kopie / backup in 93-95. Vervolgens shuck je de HDD, waarna het OS wel t/m sector 100 ziet. Het OS wil dan dus de partitietabel lezen van sector 1-3 (gaat goed) en 98-100. En dat laatste gaat dus mis, want daar staat geen partitietabel.

Als je de HDD dus opnieuw partitioneert na shucken is er verder ook niks aan de hand. Want dan komt de tabel gewoon op 1-3 en 98-100 te staan. Stop je hem daarna weer in behuizing dan gaat het dus weer mis omdat de backup partitietabel niet gelezen kan worden.

Nu ik 1 8TB dus heb vervangen kan ik hier wat mee experimenteren. De schijf weer via de USB - SATA controller aangesloten. Waarbij ik eerst gewoon domweg een sudo zpool import probeerde, wat uiteraard zou falen aangezien 2 van de 3 disks ontbreken. Echter vond deze de hele zpool niet eens:

no pools available to import

Vervolgens maar eens met fdisk naar de schijf gekeken:

$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.36.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Command (m for help): p

Disk /dev/sdb: 7.28 TiB, 8001529315328 bytes, 15627986944 sectors
Disk model: Elements 25A3   
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: F0A077EE-683E-1B4B-BCEF-B3FDB6DA6025

Device           Start         End     Sectors  Size Type
/dev/sdb1         2048 15627968511 15627966464  7.3T Solaris /usr & Apple ZFS
/dev/sdb9  15627968512 15627984895       16384    8M Solaris reserved 1

Oftewel:

The primary GPT table is corrupt, but the backup appears OK, so that will be used.

Waarbij ik een beetje verbaasd was over dat dit juist zegt dat de primaire corrupt is en de backup ok is.

Vervolgens met w de partitietabel opnieuw laten schrijven, en een nieuwe poging:

$ sudo zpool import                   
   pool: backup
     id: 15566959508052449690
  state: UNAVAIL
status: One or more devices contains corrupted data.
 action: The pool cannot be imported due to damaged devices or data.
   see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E
 config:

        backup                                         UNAVAIL  insufficient replicas
          mirror-0                                     UNAVAIL  insufficient replicas
            122832494527796001                         UNAVAIL
            13957326248032969668                       UNAVAIL
            usb-WD_Elements_25A3_31454745584B4A5A-0:0  FAULTED  corrupted data

In eerste instantie dacht ik heel snel "3 schijven, met uiteraard 2 stuks niet beschikbaar, en deze is waarschijnlijk corrupt doordat de partitietabel wellicht gedeeltelijk over (meta)data is geschreven.
Maar toen keek ik nog eens goed en viel mij op dat verwezen werd naar backup en een mirror. Dit zal dus de HDD zijn die ik in eerste instantie nog tijdelijk met oude NAS heb gebruikt en daarbij aan backup mirror is toegevoegd die uit 2 schijven bestond, 1 kreeg bad sectors, en deze heeft toen IIRC ook via de externe behuizing een tijdje in de mirror gezeten. Ik vermoed daarmee dat door de afwijkende sectoren nu (wederom) de partitietabel op het "einde van de schijf" (zoals door de USB - SATA controller gerapporteerd) is gebruikt, en deze als lijdraad is gepakt (i.p.v. de "nieuwere" aan het begin van de schijf). Vervolgens zal dus de primaire partitietabel aan het begin zijn bijgewerkt. Alleen snap ik dan niet 100% hoe ZFS nu nog de oude zpool lijkt te zien op deze schijf. Maar vervolgens dus alsnog faalt, omdat de data op de partitie dus die van de tank raidz1 zpool zal zijn.

In ieder geval heb ik nu wat food for thought om mee te experimenteren. Want ik wil an zich best de HDD via de enclosure gebruiken als zijnde offline backup. Maar het is niet heel handig dat als onverhoopt de USB - SATA controller kapot zou gaan dat ik ook meteen niet meer aan de data kan. Dus daar moet ik eens mee experimenteren. Wat er dus gebeurd als ik nu gewoon een clean start doe (nieuwe zpool) en daarna de HDD direct via SATA (of een fatsoenlijke USB - SATA controller die geen sectoren opeet) aansluit. Of dan wel de juiste primaire partitietabel wordt gelezen en die dan met opnieuw opslaan die aan het einde van de schijf wordt geplaatst etc. En daarmee de data dus leesbaar blijft.

[rikadoo]

Wat is nu de beste manier om de disken gereed te maken voor Truenas dan? Ik heb 1 disk in behuizing gedaan hele partitie verwijderd en vervolgens uit elkaar gehaald en de losse disk aan een windows bak gehangen en een partitie gemaakt. Ik heb nu 7 van deze disks 8TB in mijn Truenas hangen en worden allemaal gezien uiteraard maar wil zeker weten dat alles goed gaat voordat ik een pool maak.

[CurlyMo]

rikadoo schreef op zaterdag 5 december 2020 @ 19:42:
Wat is nu de beste manier om de disken gereed te maken voor Truenas dan? Ik heb 1 disk in behuizing gedaan hele partitie verwijderd en vervolgens uit elkaar gehaald en de losse disk aan een windows bak gehangen en een partitie gemaakt. Ik heb nu 7 van deze disks 8TB in mijn Truenas hangen en worden allemaal gezien uiteraard maar wil zeker weten dat alles goed gaat voordat ik een pool maak.

Ik zou niet klooien met partities, maar gewoon de hele schijven aan ZFS geven.

[rikadoo]

CurlyMo schreef op zaterdag 5 december 2020 @ 19:45:
[...]

Ik zou niet klooien met partities, maar gewoon de hele schijven aan ZFS geven.

Nja ik doelde meer op het hele verhaal hierboven over de geshuckte drives. Maar als ik jou zo begrijp kan ik gewoon de hele disk toevoegen aan een pool en dan moet het allemaal in orde te zijn.

Kijk als het niet hoeft ga ik er natuurlijk niet aanzitten.

[ Voor 6% gewijzigd door rikadoo op 05-12-2020 19:51 ]

[CurlyMo]

rikadoo schreef op zaterdag 5 december 2020 @ 19:51:
[...]


Nja ik doelde meer op het hele verhaal hierboven over de geshuckte drives. Maar als ik jou zo begrijp kan ik gewoon de hele disk toevoegen aan een pool en dan moet het allemaal in orde te zijn.

Als ze niet terug aan de USB controllers hoeven is dat het makkelijkst.

[RobertMe]

rikadoo schreef op zaterdag 5 december 2020 @ 19:51:
[...]


Nja ik doelde meer op het hele verhaal hierboven over de geshuckte drives. Maar als ik jou zo begrijp kan ik gewoon de hele disk toevoegen aan een pool en dan moet het allemaal in orde te zijn.

Kijk als het niet hoeft ga ik er natuurlijk niet aanzitten.

Als je de disk zo in TrueNAS gebruikt en nooit meer er aan gaat komen / die niet met data en al terug de enclosure in gaat gewoon doen wat @CurlyMo aangeeft: de hele HDD opgeven en ZFS het werk voor je laten doen.

Daarna kun je hem dan niet uit het systeem halen, terug in de enclosure, en verder gebruiken. Dan moet je wel opnieuw partitioneren. Maar waarschijnlijk ga je de HDD toch niet terug in de behuizing plaatsen, en al helemaal niet één-op-één blijven gebruiken zonder te herpartitioneren.

[rikadoo]

RobertMe schreef op zaterdag 5 december 2020 @ 20:13:
[...]

Als je de disk zo in TrueNAS gebruikt en nooit meer er aan gaat komen / die niet met data en al terug de enclosure in gaat gewoon doen wat @CurlyMo aangeeft: de hele HDD opgeven en ZFS het werk voor je laten doen.

Daarna kun je hem dan niet uit het systeem halen, terug in de enclosure, en verder gebruiken. Dan moet je wel opnieuw partitioneren. Maar waarschijnlijk ga je de HDD toch niet terug in de behuizing plaatsen, en al helemaal niet één-op-één blijven gebruiken zonder te herpartitioneren.

Nee ga ze niet meer in de enclosure hergebruiken, mocht dat wel het geval zijn dan zal het voor garantie zijn maar dat is verder niet mijn pakkie aan. Dan gaan ze gewoon zo 1 op 1 de pool in!

[HyperBart]

Q schreef op zondag 29 november 2020 @ 20:43:
[...]


Als jij werkelijk een USB3.1 10Gbps controller hebt, dan heb je waarschijnlijk gelijk en zit ik er naast. Ik ben benieuwd.

root@nas:/usbtank# zpool iostat usbtank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
usbtank     5.77G   124G      1    788  15.8K  76.6M
usbtank     5.77G   124G      0  7.81K  4.00K   709M
usbtank     7.22G   123G     15  6.13K  63.8K   579M
usbtank     8.26G   122G     15  5.42K  63.9K   558M
usbtank     9.24G   121G     14  5.20K  59.9K   502M
usbtank     10.3G   120G     12  6.21K  52.0K   597M
usbtank     11.3G   119G     12  6.43K  52.0K   596M
usbtank     11.3G   119G      0  6.26K      0   635M
usbtank     12.8G   117G      8  7.05K  36.0K   672M
usbtank     12.8G   117G      0  6.82K      0   650M
usbtank     14.3G   116G      3  6.71K  16.0K   626M
usbtank     15.8G   114G      3  6.75K  16.0K   666M
usbtank     15.8G   114G      1  6.77K  7.99K   673M
usbtank     17.3G   113G     15  5.81K  62.6K   566M
usbtank     18.9G   111G      3  5.57K  16.0K   654M
usbtank     19.4G   111G     16  4.65K  67.9K   520M
usbtank     20.4G   110G     11  4.78K  47.9K   532M
usbtank     20.7G   109G     12  6.23K  51.9K   716M
usbtank     22.2G   108G     33  4.90K   136K   523M
usbtank     22.2G   108G      1  6.46K  7.99K   671M
usbtank     23.3G   107G      7  7.03K  31.9K   652M
usbtank     24.8G   105G      7  6.28K  32.0K   599M
usbtank     24.8G   105G      0  6.37K      0   647M
usbtank     26.3G   104G      3  6.80K  16.0K   627M
usbtank     27.8G   102G      1  6.67K  7.99K   651M
usbtank     27.8G   102G      0  5.66K  3.99K   544M
usbtank     29.3G   101G     16  6.42K  66.9K   691M
usbtank     29.3G   101G      2  5.81K  12.0K   714M
usbtank     30.8G  99.2G      3  5.21K  16.0K   524M
usbtank     31.5G  98.5G     15  6.06K  63.9K   571M
usbtank     32.7G  97.3G     13  6.49K  55.9K   632M
usbtank     33.8G  96.2G     13  6.07K  55.9K   578M
usbtank     34.9G  95.1G     13  6.37K  55.9K   586M
usbtank     34.9G  95.1G      0  7.58K  3.82K   760M
usbtank     36.4G  93.6G      0  6.67K  3.99K   607M
usbtank     37.9G  92.1G      3  6.68K  16.0K   651M
usbtank     37.9G  92.1G      0  7.58K      0   768M

Da's nu een pool met 1 vdev van 6 disks waarvan er 2 missing zijn.
1 verkeerde disk geleverd en 1 had een stevige klap gekregen, zekere voor het onzekere genomen en beide aangemeld voor RMA.

Nu de pool ff lekker vol schrijven, SMART-testen en na de RMA doe ik een replace en dan vullen die nieuwe disks zich ook lekker snel en dan nog eens een SMART-test.

[ Voor 16% gewijzigd door HyperBart op 07-12-2020 22:10 ]

[GioStyle]

@HyperBart

Jij hebt dus 6 schijven in 1 grote USB enclosure zitten, begrijp ik? Kan je daar iets meer over vertellen?

[HyperBart]

GioStyle schreef op maandag 7 december 2020 @ 22:37:
@HyperBart

Jij hebt dus 6 schijven in 1 grote USB enclosure zitten, begrijp ik? Kan je daar iets meer over vertellen?

Neen neen, helaas, dat zou nog iets tof zijn. 1 USB C of A kabeltje en dan een slootje disks aansluiten.

Dit zijn 4 disks in ieder hun eigen USB enclosure en die staan nu allemaal te spinnen op mijn case, allemaal rechtop.

[ Voor 3% gewijzigd door HyperBart op 07-12-2020 22:58 ]

[GioStyle]

HyperBart schreef op maandag 7 december 2020 @ 22:52:
[...]

Neen neen, helaas, dat zou nog iets tof zijn. 1 USB C of A kabeltje en dan een slootje disks aansluiten.

Dit zijn 4 disks in ieder hun eigen USB enclosure en die staan nu allemaal te spinnen op mijn case, allemaal rechtop.

En dan in je server een usb uitbreidingskaart en zo draai je een pool? En dat werkt gewoon 100% okay?

En waarom doe je het zo? Ik bedoel, als je straks 6 externe schijven hebt staan, dan heb je ook 6 stekkers van de voedingen? Dat maakt je niets uit?

Sorry voor de vele vragen, vind zo'n setup best fascinerend.

[HyperBart]

HyperBart schreef op zaterdag 28 november 2020 @ 13:44:
Met black friday 6 x WD 12TB op de kop kunnen tikken voor 1126 EUR .

Binnenkort shucken maar eerst eens kijken hoe ze werken icm ZFS en USB3.1.

GioStyle schreef op maandag 7 december 2020 @ 23:12:
[...]


En dan in je server een usb uitbreidingskaart en zo draai je een pool?

Nee hoor, gewoon ieder diskje met een USB kabeltje op het moederbord. 2 op de achterkant en 2 via het front panel

En dat werkt gewoon 100% okay?

Jup, heb alleen mijn pool ergens verkeerd aangemaakt denk ik want ik heb maar 130GB space. Maar dat is ongetwijfeld omdat ik met 2 sparse files heb zitten werken.

En waarom doe je het zo? Ik bedoel, als je straks 6 externe schijven hebt staan, dan heb je ook 6 stekkers van de voedingen? Dat maakt je niets uit?

Oh jawel, oh jawel. Alhoewel het ook nog best leuk zou zijn om een centrale PSU te voorzien en die disks zo allemaal te poweren om het efficienter te maken.

Neen, dat is dus niet de bedoeling. Die disks zijn nu net aangekomen, ik ga ze nu even een paar weken laten draaien en flink inbranden om te kijken of er SMART fouten optreden en daarna gaat de USB enclosure er van af en dan bouw ik ze in in mijn server... Dat heet het "shucken" van disks.

https://www.backblaze.com/blog/backblaze_drive_farming/
https://nl.ifixit.com/Gui...xternal+Hard+Drive/137646

Sorry voor de vele vragen, vind zo'n setup best fascinerend.

[GioStyle]

HyperBart schreef op maandag 7 december 2020 @ 23:27:

Jup, heb alleen mijn pool ergens verkeerd aangemaakt denk ik want ik heb maar 130GB space. Maar dat is ongetwijfeld omdat ik met 2 sparse files heb zitten werken.

Been there done that. Als ik het me goed herinner moet je zpool set autoexpand=on doen en dan je 2 ontbrekende schijven aansluiten en dan heb je je volledige capaciteit.

GioStyle in "Het grote ZFS topic"
GioStyle in "Het grote ZFS topic"

[ Voor 5% gewijzigd door GioStyle op 07-12-2020 23:43 ]

[Q]

HyperBart schreef op maandag 7 december 2020 @ 22:06:
[...]

root@nas:/usbtank# zpool iostat usbtank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
usbtank     5.77G   124G      1    788  15.8K  76.6M
usbtank     5.77G   124G      0  7.81K  4.00K   709M
usbtank     7.22G   123G     15  6.13K  63.8K   579M
usbtank     8.26G   122G     15  5.42K  63.9K   558M
usbtank     9.24G   121G     14  5.20K  59.9K   502M
usbtank     10.3G   120G     12  6.21K  52.0K   597M
usbtank     11.3G   119G     12  6.43K  52.0K   596M
usbtank     11.3G   119G      0  6.26K      0   635M
usbtank     12.8G   117G      8  7.05K  36.0K   672M
usbtank     12.8G   117G      0  6.82K      0   650M
usbtank     14.3G   116G      3  6.71K  16.0K   626M
usbtank     15.8G   114G      3  6.75K  16.0K   666M
usbtank     15.8G   114G      1  6.77K  7.99K   673M
usbtank     17.3G   113G     15  5.81K  62.6K   566M
usbtank     18.9G   111G      3  5.57K  16.0K   654M
usbtank     19.4G   111G     16  4.65K  67.9K   520M
usbtank     20.4G   110G     11  4.78K  47.9K   532M
usbtank     20.7G   109G     12  6.23K  51.9K   716M
usbtank     22.2G   108G     33  4.90K   136K   523M
usbtank     22.2G   108G      1  6.46K  7.99K   671M
usbtank     23.3G   107G      7  7.03K  31.9K   652M
usbtank     24.8G   105G      7  6.28K  32.0K   599M
usbtank     24.8G   105G      0  6.37K      0   647M
usbtank     26.3G   104G      3  6.80K  16.0K   627M
usbtank     27.8G   102G      1  6.67K  7.99K   651M
usbtank     27.8G   102G      0  5.66K  3.99K   544M
usbtank     29.3G   101G     16  6.42K  66.9K   691M
usbtank     29.3G   101G      2  5.81K  12.0K   714M
usbtank     30.8G  99.2G      3  5.21K  16.0K   524M
usbtank     31.5G  98.5G     15  6.06K  63.9K   571M
usbtank     32.7G  97.3G     13  6.49K  55.9K   632M
usbtank     33.8G  96.2G     13  6.07K  55.9K   578M
usbtank     34.9G  95.1G     13  6.37K  55.9K   586M
usbtank     34.9G  95.1G      0  7.58K  3.82K   760M
usbtank     36.4G  93.6G      0  6.67K  3.99K   607M
usbtank     37.9G  92.1G      3  6.68K  16.0K   651M
usbtank     37.9G  92.1G      0  7.58K      0   768M

Da's nu een pool met 1 vdev van 6 disks waarvan er 2 missing zijn.
1 verkeerde disk geleverd en 1 had een stevige klap gekregen, zekere voor het onzekere genomen en beide aangemeld voor RMA.

Nu de pool ff lekker vol schrijven, SMART-testen en na de RMA doe ik een replace en dan vullen die nieuwe disks zich ook lekker snel en dan nog eens een SMART-test.

150 MB/s schrijven per disk is top. Ik ben benieuwd of je de 900MB/s aan gaat tikken met de 2 missende schijven.

Ik draaide ~18 jaar terug met 3 x 320GB in RAID5 via USB2 waarbij iedere disk zijn eigen PCI USB 2.0 kaart had. Hot-swap voor weinig. 😜

[HyperBart]

Q schreef op dinsdag 8 december 2020 @ 00:57:
[...]


150 MB/s schrijven per disk is top. Ik ben benieuwd of je de 900MB/s aan gaat tikken met de 2 missende schijven.

Ik draaide ~18 jaar terug met 3 x 320GB in RAID5 via USB2 waarbij iedere disk zijn eigen PCI USB 2.0 kaart had. Hot-swap voor weinig. 😜

Nah heb nu een dd openstaan om 40TB weg te schrijven en het hoogste wat ik tegenkwam was die 800+ in het begin. Of je bedoelt als ik die 2 missende disks er ook bij aan hang? Dan waarschijnlijk wel, maar netto in schrijfsnelheid voor dd gaat het niets uitmaken veronderstel ik want het is dan 2 x parity

Maar bij deze, voor diegene die echt met een gebrek aan ruimte zit... USB 3 WD Elements en je kan er weer even tegen

[ Voor 6% gewijzigd door HyperBart op 08-12-2020 01:01 ]

[WeaZuL]

In aanvulling op het SMR verhaal, heb dit weekend twee geshuckte ST2000LM003 schijven in mirror vervangen door twee tevens geshuckte ST5000LM000 (SMR) 15mm schijven. Om +/- 2 TB te resilveren was er 1,5 dag voor nodig om dit succesvol af te ronden (per schijf). Snel is anders maar voor de toepassing is dit geen issue voor mij.

[HollowGamer]

Ik heb 4 schijven als één grote pool (3x 4TB, 1x 8TB):

code:

$ df -h
zfsdata           6.3T  128K  6.3T   1% /mnt/data
zfsdata/private    18T   12T  6.3T  64% /mnt/data/private
zfsdata/public    6.6T  343G  6.3T   6% /mnt/data/public

Ik heb één schijf uit dit volume (zfsdata) gehaald en vervolgens één van 8TB toegevoegd. Er zijn twee datasets, één voor publiek (voor video, etc.) en één gedeelde voor private stuff.

Wat ik zo raar vind is hoe het wordt weergeven, ik heb de schijf aan de pool als volgt:

code:

zpool add zfsdata ata-WDC_WD80EDAZ-11TA3A0_VGH9DPWG

code:

$ zpool status -v
  pool: zfsdata
 state: ONLINE
 status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
 action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
 see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-8A
 scan: scrub repaired 0B in 10:31:17 with 1 errors on Tue Dec  1 10:31:19 2020
config:

        NAME                                        STATE     READ WRITE CKSUM
        zfsdata                                     ONLINE       0     0     0
          wwn-0x50014ee210e5d1d8                    ONLINE       0     0     0
          wwn-0x50014ee2663b1aba                    ONLINE       0     0     0
          ata-WDC_WD40EFRX-68N32N0_WD-WCC7K6SPSDD0  ONLINE       0     0     0
          ata-WDC_WD80EDAZ-11TA3A0_VGH9DPWG         ONLINE       0     0     0

Het is wel raar hoe hij de eerste 2 aangeeft, maar ik heb dus meerdere van dezelfde erin zitten, misschien is dit het probleem?

Is dit een probleem? Moet ik opnieuw beginnen?

[HyperBart]

Je weet/beseft dat je nu geen redundantie hebt? Je hebt als het ware al je disks aan elkaar geplakt en er één grote seriele disk van gemaakt. Dat is nog los van je probleem waar je vraag rond gaat.

Disk kapot = data van die disk minstens kwijt, ik weet niet of ZFS zo intelligent is dat het falen van één disk in een pool alleen de files op die disk als verloren markeert of dat je dan tout court alles kwijt bent.

Post eens een ls -lah van je /dev/ en de labels de je nu hebt gepost?

[ Voor 43% gewijzigd door HyperBart op 09-12-2020 16:58 ]

[itcouldbeanyone]

Ben bezig mijn hypervisor het ZFS systeem een beetje op orde te krijgen.
zit nu een aantal PCIE SSD's in voor caching, (SLC)
nu wil ik een slog maken verdeeld over 8 SSD's in een soort RAID 10.
ik lees overal dat slog mirrored moet zijn, en zo snel mogelijk.
als ik 4 x een mirrored slog toevoeg aan me zpool, is het dan automatisch een stripped mirror (raid10) ?
ik wil uiteindelijk een slog van 12GB gebruiken, (flushtime x snelheid pool). (met SLC zou dan na 1200TB de cells van de slog versleten zijn)
de rest gaat naar l2arc en overprovision.

[HollowGamer]

HyperBart schreef op woensdag 9 december 2020 @ 16:11:
Je weet/beseft dat je nu geen redundantie hebt? Je hebt als het ware al je disks aan elkaar geplakt en er één grote seriele disk van gemaakt. Dat is nog los van je probleem waar je vraag rond gaat.

Disk kapot = data van die disk minstens kwijt, ik weet niet of ZFS zo intelligent is dat het falen van één disk in een pool alleen de files op die disk als verloren markeert of dat je dan tout court alles kwijt bent.

Post eens een ls -lah van je /dev/ en de labels de je nu hebt gepost?

Dat weet ik en is niet erg.

Ik maak dagelijks een backup naar mijn externe schijf (2x 8TB) met borg (incl. versiebeheer) en ik gebruik Syncthing tussen mijn apparaten. In de toekomst wil ik naar een betere oplossing, maar voor nu heb ik daar even geen budget voor. Wat zou hiervoor de beste oplossing zijn overigens? Ik heb ruimte voor 4x HDD's of ik moet een extra SATA-controller erbij kopen (moederbord heeft maar 4 poorten).

Wat bedoel je precies met /dev/? Ik gebruik hiervoor disk-id's.

Thanks.

[ Voor 7% gewijzigd door HollowGamer op 10-12-2020 13:47 ]

[dcm360]

@HollowGamer De enige manier die werkt om een schijf te vervangen door een andere (met jouw configuratie), is met zpool replace terwijl de oude en nieuwe schijf aangesloten zijn. Een schijf die je met zpool add hebt toegevoegd, is niet meer te verwijderen.

[HollowGamer]

dcm360 schreef op donderdag 10 december 2020 @ 14:04:
@HollowGamer De enige manier die werkt om een schijf te vervangen door een andere (met jouw configuratie), is met zpool replace terwijl de oude en nieuwe schijf aangesloten zijn. Een schijf die je met zpool add hebt toegevoegd, is niet meer te verwijderen.

Dat is niet wat ik zoek, ik wil juist weten of de zpool klopt.
Ik zou in totaal 16TB nu moeten hebben, maar vind het zo raar dat zfsdata/public niet lijkt te kloppen.

[dcm360]

De output van df lijkt mij verder wel correct. In df geldt dat Size = Used + Avail, en dat telt zo te zien gewoon op.

[FireDrunk]

ZFS toont doorgaans TiB (1024 tallen) ipv TB (1000 tallen). De capaciteit van je schijven wordt eigenlijk altijd aangeduid in TB.

Wikipedia: Tebibyte
vs
Wikipedia: Terabyte

[HollowGamer]

@dcm360 @FireDrunk Ok, thanks!

Nog een laatste vraag - ik heb twee datasets (zfsdata/private & zfsdata/public), als ik data verplaatst tussen die twee mount points is hij aan het schrijven en lezen. Ik zou verwachten dat ik op dezelfde zfsdata zpool zit, dat dit niet zou hoeven. Is dit normaal? Of is er iets fout in mijn zpool?

[FireDrunk]

Nee, verschillende filesystems kunnen verschillende instellingen (properties) hebben als compressie, dedup, etc.
Daardoor zijn het echt verschillende entiteiten om naar te schrijven.

[kdbruin]

Draai sinds een tijdje Debian Buster met ZFS on Root. Werkt zonder problemen en heb daarom recentelijk een tweede SSD in m'n omgezet van ext4 naar een nieuwe pool. Probleem is echter dat de nieuwe na een reboot niet wordt geïmporteerd. Ik heb al gezocht maar kan veel vinden over het probleem maar geen oplossing die werkt.

Zowel de instelling

ZPOOL_IMPORT_ALL_VISIBLE="yes"

en

ZFS_POOL_IMPORT="dpool1"

in /etc/defaults/zfs maakt geen verschil. Ook de verschillende systemd services zijn enabled. In de logs zie ik namelijk dat er een import wordt gedaan maar er niets wordt geïmporteerd.

Na een reboot kan ik handmatig een import doen zonder problemen.

Hebben er hier meer mensen last van?

[ Voor 3% gewijzigd door kdbruin op 15-12-2020 10:52 ]

[FireDrunk]

Staat het ZFS Filesystem wel op automount? Er is een 'manual' optie op een filesystem, dan automount ZFS dat specifieke filesystem niet. (Je wordt dan geacht dat in /etc/fstab zelf te doen)

[GioStyle]

@kdbruin

Krijg je geen foutmelding bij het opstarten? Iets over ZFS automount?

Ik was gisteren namelijk ook bezig met Debian en ZFS.

Ik heb een pool die gemount wordt op /mnt. Op die pool heb ik ook nog een filesystem /Backups die gemount wordt als /mnt/backups. Debian vindt dat blijkbaar niet zo leuk, omdat eerst /mnt wordt gemount en daarna /mnt/backups. Maar omdat /mnt niet leeg is, geeft het een foutmelding. Ik heb de mountpoint van /mnt/backups naar /backups veranderd en het probleem was gelijk opgelost.

Misschien bij jou ook zoiets aan de hand?

[kdbruin]

@FireDrunk @GioStyle Het systeem heeft geen filesysteem om te mounten aangezien de import van de pool niet wordt gedaan. Handmatig de pool importeren mount ook het juiste filesystem op de juiste plek in de totale boom.

[meraki]

Twee vragen:

Eerste vraag
Deze zomer gaf een bepaalde schijf problemen in mijn RAIDZ-1 opstelling.



Op dit moment is de status van de schijf echter als volgt:



Ik vermoed dat ik deze maar eens moet gaan vervangen ondanks dat de status nu terug op ONLINE i.p.v. DEGRADED staat. Indien ik dat doe, wat doe ik dan het best:

• Een backup maken van alle data naar een externe HDD-schijf alvorens ik de schijf vervang om zo een onfortuinlijke resilver te vermijden?
• Of is dit onzinnig in mijn geval aangezien de vdev die voorheen op degraded stond nu terug online staat en kan de resilver aldus veilig verlopen?

Tweede vraag

Ik heb de mogelijkheid om te upgraden naar OpenZFS 2.0. Doe ik dit best eerst alvorens de schijf te vervangen? Het zou dan gaan om een simpele zpool export en zpool import en nadien de laatste nieuwe feature flags aanzetten. Ik las namelijk dat het resilveren hiermee sneller verloopt.

Alvast bedankt voor jullie advies.

[ Voor 5% gewijzigd door meraki op 18-12-2020 20:16 ]

[CurlyMo]

meraki schreef op vrijdag 18 december 2020 @ 20:13:

• Een backup maken van alle data naar een externe HDD-schijf alvorens ik de schijf vervang om zo een onfortuinlijke resilver te vermijden?
• Of is dit onzinnig in mijn geval aangezien de vdev die voorheen op degraded stond nu terug online staat en kan de resilver aldus veilig verlopen?

De vraag is sowieso of het wel de HDD is en niet iets anders. Geheugen, kabels, e.d.

[meraki]

CurlyMo schreef op vrijdag 18 december 2020 @ 20:18:
[...]

De vraag is sowieso of het wel de HDD is en niet iets anders. Geheugen, kabels, e.d.

Bedankt. Hoe onderzoek ik dit best?

[CurlyMo]

meraki schreef op vrijdag 18 december 2020 @ 20:19:
[...]


Bedankt. Hoe onderzoek ik dit best?

Een memtest86 draaien voor tenminste 24 uur. Heb je ECC geheugen?

[meraki]

CurlyMo schreef op vrijdag 18 december 2020 @ 20:20:
[...]

Een memtest86 draaien voor tenminste 24 uur. Heb je ECC geheugen?

Ik heb inderdaad ECC-geheugen.

[CurlyMo]

meraki schreef op vrijdag 18 december 2020 @ 20:20:
[...]


Ik heb inderdaad ECC-geheugen.

Dan is de kans groot dat dat het niet is. Waar ik mee zou beginnen is de een zpool clear, daarna een scrub, wanneer nodig weer een clear, en dan weer een scrub. Dan weet je zeker of het een tijdelijk probleempje was. Als er dan fouten blijven optreden, dan zou ik pas verder zoeken.

[meraki]

CurlyMo schreef op vrijdag 18 december 2020 @ 20:22:
[...]

Dan is de kans groot dat dat het niet is. Waar ik mee zou beginnen is de een zpool clear, daarna een scrub, wanneer nodig weer een clear, en dan weer een scrub. Dan weet je zeker of het een tijdelijk probleempje was. Als er dan fouten blijven optreden, dan zou ik pas verder zoeken.

Dit is de output van de laatste scrub:

scan: scrub repaired 18.0M in 31h35m with 0 errors on Mon Nov 16 07:35:27 2020

NAME STATE READ WRITE CKSUM
gptid/5874768a-445e-11e2-a81b-000c29751855 ONLINE 0 0 14.7

Dit gaat zo al sinds elke grote scrub sinds het voorval in juni.

[CurlyMo]

meraki schreef op vrijdag 18 december 2020 @ 20:25:
[...]


Dit is de output van de laatste scrub:

scan: scrub repaired 18.0M in 31h35m with 0 errors on Mon Nov 16 07:35:27 2020

NAME STATE READ WRITE CKSUM
gptid/5874768a-445e-11e2-a81b-000c29751855 ONLINE 0 0 14.7

Dit gaat zo al sinds elke grote scrub sinds het voorval in juni.

Wat ik al zei. Een zpool clear en weer (handmatig) scrubben.

[meraki]

Wat ik al zei. Een zpool clear en weer (handmatig) scrubben.

Prima. Doe ik en ik zie al gelijk dat 'ie de desbetreffende schijf begint te repairen:

gptid/5874768a-445e-11e2-a81b-000c29751855 ONLINE 0 0 0 (repairing)

[CurlyMo]

meraki schreef op vrijdag 18 december 2020 @ 20:44:
[...]


Prima. Doe ik en ik zie al gelijk dat 'ie de desbetreffende schijf begint te repairen:

gptid/5874768a-445e-11e2-a81b-000c29751855 ONLINE 0 0 0 (repairing)

Dat is niet erg. Daarom doe je na deze scrub weer hetzelfde nog een keer om te checken of het inderdaad niet tijdelijk is.