Het grote ZFS topic

[Verwijderd]

Je hebt dus geen snapshots? Geldt dit ook voor ZFS volumes (ZVOLs)? Die kunnen ook sparse zijn aangemaakt namelijk.

Kun je uitleggen wat je precies hebt gedaan? Als je van een oudere versie naar een nieuwe versie bent gegaan, is het prima mogelijk dat ZFS zich anders gedraagt en dus ook invloed heeft op de beschikbare ruimte.

[Loekie]

Ook geen ZVOLs.
Heb vermoeden waar het probleem zit:
Heb oude machine uitgezet(ZFSGURU 0.2.0rc, system 10.1.001), disk overgeheveld naar nieuwe machine waar ik al laatste versie van ZFSGURU heb draaien(0.3.1, system: 10.2.003), hier geïmporteerd.
Ik begrijp dat een zpoolexport handig was geweest, doch niet strict noodzakelijk.
Zal de scrub even afwachten.

[Verwijderd]

Eerst exporteren had niets uitgemaakt. Dat hele export & import gedoe is om te voorkomen dat je pool door twee ZFS implementaties tegelijk wordt gebruikt, zoals in zeer bijzondere situaties kan voorkomen.

Scrub mag ook niets uitmaken.

Enige wat ik kan bedenken is dat de nieuwe BSD versie die je nu draait, commits heeft die ZFS anders laat gedragen met als resultaat andere berekening van beschikbare/bruikbare vrije ruimte. Sowieso is het niet verstandig je pool zo vol te maken. Eigenlijk moet je nu alles backuppen en je pool vernietigen. Dit krijg je namelijk nooit meer ongedaan die fragmentatie.

[syl765]

Misschien heb je last van de nieuwe space reservation.
Nieuwere pools reserveren iets meer ruimte, het kan zijn dat je hierdoor in de problemen komt.

http://lists.freebsd.org/...2014-November/020429.html
spa_slop_shift is de tunable , even googlelen .

[Loekie]

Daar lijkt het wel op, ook op nieuwe array van 36TiB wordt 30TB getoond waar ik 33TB verwacht had.
Zal vanavond eens uitzoeken.
Heb inmiddels wel wat 'ruimte' gemaakt door files te verwijderen.

[ Voor 20% gewijzigd door Loekie op 14-09-2015 09:02 ]

[Verwijderd]

eerste test c: op 1 raid0 (2 raidz met elk 3 wd red nas disks en 2 ssd's (raid0) voor zil)

en dan hier wat betere weergave v.d. werkelijkheid

[ Voor 26% gewijzigd door Verwijderd op 14-09-2015 10:37 ]

[syl765]

Loekie schreef op maandag 14 september 2015 @ 09:00:
Daar lijkt het wel op, ook op nieuwe array van 36TiB wordt 30TB getoond waar ik 33TB verwacht had.
Zal vanavond eens uitzoeken.
Heb inmiddels wel wat 'ruimte' gemaakt door files te verwijderen.

Mocht je snapshots gebruiken, vergeet die dan ook niet te verwijderen!
Anders ruim je als nog niets op !

[F-Tim]

Ik moet zeggen, ik zie door de bomen een beetje het bos niet meer, en ik kan ook met heel wat googlen niet echt concrete antwoorden vinden dus ik hoop dat jullie me een beetje op weg kunnen helpen.

Ter info, ik heb op dit moment nog géén NAS, ben me dus nog aan het orienteren op wat ik wil gaan starten zodat ik in 1 klap de goede start maak mét voldoende toekomstige upgrade mogelijkheden.

RAID5/6 wordt overal afgeraden omdat het ontzettend veel tijd kost om een array met disks met veel TB's te repairen en dus je risico erg groot wordt dat er tijdens een repair fouten optreden en je alsnog je hele array verloren bent. Zodoende ben ik via een vriend op ZFS uitgekomen en ben ik me hier op gaan orienteren.

Wat ik heb liggen thuis, 2x WD Red 3TB en 2x WD Red 4TB. de 3TB's zijn ongebruikt, de 4TB's staan beide vol. Op dit moment dus een 8TB aan data die bij een schijfcrash letterlijk weg is. Zodoende dus ook steeds meer de neiging om een goed (zelfbouw) NAS in te richten.

Aangezien ZFS geen Online Capacity Expansion kent was mijn intiele plan om 1x een 3TB en 1x 4TB disk erbij te kopen, 2 diskpools te maken. Starten met 3x 3TB in één RAID-Z1 (dus 6TB beschikbaar), dan de data van de 4TB's kopieren naar de NAS en andere externe disks die ik heb liggen. Dan van de 3x 4TB een 2de RAID-Z1 diskpool maken (dus 8TB beschikbaar) en dán de beide diskpools aan elkaar knopen zodat er 1 grote 14TB set beschikbaar was als NAS. Immers, tijdens de initialisatie van een diskpool wordt alle data verwijderd en dus was mijn idee om het in 2 stappen te doen.

Voor mijn gevoel waren de voordelen als volgt:
- Meer disks, dus hogere performance met schrijven
- 2 parity disks, dus technisch gezien mogen 2 schijven crashen (mits ze uit 2 diskpools komen, als 2 schijven uit 1 diskpool crashen ben k alsnog de sjaak en is alle 14TB verloren), een soort van RAID-Z1½ dus...
- 1 grote dataset in plaats van 2 kleinere waarover ik zelf de data zou gaan verdelen.

Nadeel:
- bij een volgende (replacement) upgrade zou ik automatisch weer 3x 4TB moeten kopen, en dan kom ik op 16TB beschikbare ruimte uit. (6TB en 8TB zijn op t moment veel te duur, en ik verwacht niet dat die veel zullen gaan dalen in prijs), wat me bij de volgende situatie bracht....

Alternatief zat ik te twijfelen om 3x WD Red 4TB bij te kopen, en dan een 5-disk RAID-Z1 array te maken met als totaal 16TB ruimte.

Nadelen t.o.v. eerdere configuratie:
- Initieel (marginaal) duurder dan eerder genoemde configuratie
- 1 parity disk, dus bij 2 disk crashes is écht alles weg

Voordelen
- "Maar" 5 disks in plaats van 6, dus eventueel ruimte om een SSD als caching toe te voegen aan het array (uitgaande van een 6 SATA mobo)?
- Meer effectieve opslag ruimte (16TB vs 14TB).
- 2x 3TB Red's 'over', met als gevolg dat ik daar nog kritische data op zou kunnen backuppen (Foto's bv) en die op 2 geolocaties kan bewaren.
- Met het upgradepad van de eerste optie in het achterhoofd is dit op lange termijn goedkoper mocht ik de 14TB vol krijgen.

Opvolgend ben ik op zoek gegaan naar ZFS Reliability calculators online om te bepalen wat hierin wijsheid was. Immers, je wil een zo efficient mogelijke reliability - schijfruimte - kosten verdeling. Helaas is hier niks van te vinden online, de calculators die ik vind hebben allen slechts de mogelijkheid om 1 diskpool aan te maken en dáár de reliability van te berekenen. En ik heb er een flink aantal gezocht... heb ook een Excel sheet gevonden, maar daar werd ik niet heel erg wijs uit.

Ik loop dus een beetje vast en vind ik meer vragen dan antwoorden. Voor ik dus nóg verder ga en nóg meer vragen dan antwoorden ga krijgen wil ik hier om wat ervaringsdeskundigen vragen.

- Kloppen mijn aannames, voor- en nadelen? En dan met name ook m.b.t. de 2 parity disks en de meer redundantie bij mijn 1ste oplossing? Of heft het koppelen van de diskpools dit weer op?
- Wat zou de voorkeur hebben? En nog veel belangrijker waarom?
- Is het stripen van een diskpool überhaupt mogelijk met behoud van data?
- Is er een mogelijkheid om de data te verdelen nadat de pools gekoppeld zijn? Ik las wel dat je een map kon kopieren binnen het array, dan zou de nieuwe variant verdeeld worden binnen het array, en dan de oorspronkelijke (niet verdeelde) map verwijderen.

Ik hoop dat jullie me op gang kunnen helpen en ik een goeie start kan maken als ik met een NAS ga beginnen

Het NAS is voor thuisgebruik en het maakt dus niet uit als ik bij een disk crash 1 dag tijd kwijt ben om mijn array op te bouwen. Immers, als tijd een issue was, dan zou RAID10 met 8x 4TB disks de voorkeur genieten om op de 16TB uit te komen.

[Verwijderd]

RAID5/6 wordt overal afgeraden omdat het ontzettend veel tijd kost om een array met disks met veel TB's te repairen en dus je risico erg groot wordt dat er tijdens een repair fouten optreden en je alsnog je hele array verloren bent. Zodoende ben ik via een vriend op ZFS uitgekomen en ben ik me hier op gaan orienteren.

met zfs kun je ook het bokkie zijn als er nóg 1 afscheid neemt tijdens een resilver. enige voordeel van zfs is dat het alleen gebruikte blocks leest en schrijft en niet als hw raid álle blocks oftewel als je pool erg vol zit is de kans met zfs nagenoeg net zo groot als met hw raid.

[syl765]

- Kloppen mijn aannames, voor- en nadelen? En dan met name ook m.b.t. de 2 parity disks en de meer redundantie bij mijn 1ste oplossing? Of heft het koppelen van de diskpools dit weer op?
- Wat zou de voorkeur hebben? En nog veel belangrijker waarom?
- Is het stripen van een diskpool überhaupt mogelijk met behoud van data?
- Is er een mogelijkheid om de data te verdelen nadat de pools gekoppeld zijn? Ik las wel dat je een map kon kopieren binnen het array, dan zou de nieuwe variant verdeeld worden binnen het array, en dan de oorspronkelijke (niet verdeelde) map verwijderen.

Ik zou proberen of je de diskpools (vdevs) in een raidz2 kan plaatsen, minder capaciteit, maar wel veel bedrijfs zekerder.
Het stripen is prima mogelijk over meerdere disk pools (vdevs).
Je voegd gewoon de vdev toe aan de pool zpool add poolnaam raidz(x) disk_a disk_b disk_c disk_d enz

Het belanceren van de data is niet mogelijk zonder dit soort kopieer acties inderdaad. Hier word wel aan gewerkt volgens mij maar is nog niet aanwezig. Het is wel zo dat als je gaat kopieeren dat ZFS de nieuwe vdev meer gebruikt als de oude. Dus echt gebalaceerd is die data dan ook niet aangezien er nu meer op de nieuwe vdev staat dan de oude.

[Q]

F-Tim schreef op maandag 14 september 2015 @ 11:02:
Ik moet zeggen, ik zie door de bomen een beetje het bos niet meer, en ik kan ook met heel wat googlen niet echt concrete antwoorden vinden dus ik hoop dat jullie me een beetje op weg kunnen helpen.

Ter info, ik heb op dit moment nog géén NAS, ben me dus nog aan het orienteren op wat ik wil gaan starten zodat ik in 1 klap de goede start maak mét voldoende toekomstige upgrade mogelijkheden.

RAID5/6 wordt overal afgeraden omdat het ontzettend veel tijd kost om een array met disks met veel TB's te repairen en dus je risico erg groot wordt dat er tijdens een repair fouten optreden en je alsnog je hele array verloren bent. Zodoende ben ik via een vriend op ZFS uitgekomen en ben ik me hier op gaan orienteren.

Edit: RAID6 is opzich ok, een rebuild gaat redelijk vlot. 5 uur per TB is mijn ervaring.
ZFS heeft als voordeel dat het alleen de data hoeft te rebuilden dus als je maar 50% gebruikt gaat een rebuild sneller. Maar daar koop je weinig voor als je array al voor 70% vol zit.

Wat ik heb liggen thuis, 2x WD Red 3TB en 2x WD Red 4TB. de 3TB's zijn ongebruikt, de 4TB's staan beide vol. Op dit moment dus een 8TB aan data die bij een schijfcrash letterlijk weg is. Zodoende dus ook steeds meer de neiging om een goed (zelfbouw) NAS in te richten.

Aangezien ZFS geen Online Capacity Expansion kent was mijn intiele plan om 1x een 3TB en 1x 4TB disk erbij te kopen, 2 diskpools te maken. Starten met 3x 3TB in één RAID-Z1 (dus 6TB beschikbaar), dan de data van de 4TB's kopieren naar de NAS en andere externe disks die ik heb liggen. Dan van de 3x 4TB een 2de RAID-Z1 diskpool maken (dus 8TB beschikbaar) en dán de beide diskpools aan elkaar knopen zodat er 1 grote 14TB set beschikbaar was als NAS. Immers, tijdens de initialisatie van een diskpool wordt alle data verwijderd en dus was mijn idee om het in 2 stappen te doen.

Alhoewel ik anders heb beweerd zou ik zelf ook thuis niet snel meer RAIDZ1 toepassen. Je wilt niet bij uitval van 1 schijf je redundancy verliezen. Juist thuis niet omdat het niet betaalbaar / realistisch is om alle data ook nog eens te backuppen. Maar dat is jouw keuze.

Ik zie zelf niet echt een mooi upgrade pad met 2 x 3 TB en 2 x 4 TB.

Ik zou zelf adviseren om de 3 TB disks links te laten liggen en 4 x 4 TB er bij te kopen, zodat je de komende jaren wel gebakken zit met 16 TB.

Een minder mooi maar werkend alternatief is om 2 x 4 TB er bij te kopen en vervolgens zowel de 3 TB als 4 TB disks in een 6-disk RAIDZ2 te zetten. Dat geeft 12 TB capaciteit.
Als je later de 3 TB disks eens vervangt door 4 TB disks dan kun je je pool expanden tot 16 TB. Dit pad is initieel goedkoper.

Het probleem van losse VDEVs is dat je dan extra schijven kwijt bent aan redundancy, dus een enkele grote VDEV is altijd efficienter.

Voor mijn gevoel waren de voordelen als volgt:
- Meer disks, dus hogere performance met schrijven

Performance is totaal niet relevant voor thuis zou ik zeggen, gigabit trek je wel vol met 1 disk.

[ Voor 4% gewijzigd door Q op 14-09-2015 12:26 ]

[CurlyMo]

Je kan altijd 4x3TB maken met je 3TB + 4TB en bijvoorbeeld een aparte pool voor download meuk op die overige 2x1TB.

[FireDrunk]

2*3TB in mirror, en 2*4TB in mirror.
Later backup je de belangrijkste dingen naar je 2*3TB, koop je 2 of meer 4TB schijven erbij, breekt de mirror, maakt een RAIDZ aan met een missende disk, kopieert de data, en voegt de laatste 4TB disk toe voor extra redundancy.

[DaCoTa]

Q schreef op maandag 14 september 2015 @ 12:23:
[...]
Een minder mooi maar werkend alternatief is om 2 x 4 TB er bij te kopen en vervolgens zowel de 3 TB als 4 TB disks in een 6-disk RAIDZ2 te zetten. Dat geeft 12 TB capaciteit.
Als je later de 3 TB disks eens vervangt door 4 TB disks dan kun je je pool expanden tot 16 TB. Dit pad is initieel goedkoper.
[...]

Dit is het pad wat ik nu al een aantal jaren aan het bewandelen ben, en dat gaat erg eenvoudig. Ik ben met 3x2TB begonnen die vol zaten, gewoon losse disks. Ik heb daar met wat heen en weer gemigreer een Z2 gemaakt met die 3x2TB aangevuld met nieuwe 3x3TB, wat netto 8TB opleverde.

Inmiddels zijn is er een 2TB en een 3TB overleden en die zijn beide vervangen door 4TB disks, waardoor het nu 2x2TB, 2x3TB en 2x4TB is. Ik heb nog geen ruimtegebrek, maar ik kan dus dan vrij eenvoudig, zonder alle parity op te geven, de 2TBs vervangen voor wat er dan de beste €/GB verhouding heeft.

Het is nu nog steeds dus 8TB netto, zoals ik hem ooit gemaakt heb, maar dat schaalt vanzelf wel door, of omdat schijven overlijden, of omdat ik wil uitbreiden als het nodig gaat zijn.

Wat ik hier prettig aan vind is dat de initiele investering laag is, er weinig bewegende onderdelen zijn en schijven over tijd toch goedkoper worden, dus met een ongeveer constante kosten over tijd (1 nieuwe schijf per 2 a 3 jaar) de pool toch langzaam groter wordt.

[ Voor 10% gewijzigd door DaCoTa op 14-09-2015 13:40 ]

[F-Tim]

Q schreef op maandag 14 september 2015 @ 12:23:
[...]

Een minder mooi maar werkend alternatief is om 2 x 4 TB er bij te kopen en vervolgens zowel de 3 TB als 4 TB disks in een 6-disk RAIDZ2 te zetten. Dat geeft 12 TB capaciteit.
Als je later de 3 TB disks eens vervangt door 4 TB disks dan kun je je pool expanden tot 16 TB. Dit pad is initieel goedkoper.

Eigenlijk lijkt me dit ook wel een prima startpad... lange termijn wél een volledige 2 disk redundancy. Hoewel het initieel het nadeel van minder beschikbare ruimte, vond ik het lange termijn voordeel beter (en voordat ik aan de 12TB kwam zou toch nog wel ff duren)

Enige wat ik als "klein" probleem voorzie bij bovenstaand pad, is dat bij de initialisatie van het array alles geformatteeerd wordt. Met als gevolg, dat ik hierbij het array eigenlijk niet kan initialiseren zonder dataverlies. De 8TB kan ik niet zomaar elders parkeren, ik denk dat ik met goed m'n best doen op ongeveer 4TB aan flex-storage ga komen, maar dan verlies ik dus alsnog 4TB data. Of zie ik het nu verkeerd? Beter gezegd, is er een optie om wél te richting die 6x4TB Z2 oplossing te gaan op termijn zonder initieel dataverlies?

Als oplossing daarvoor bedacht ik een extra 4TB te kopen, maar dan koop ik alsnog 3x 4TB... dus ik denk, dan meteen met 5x 4TB Z1 starten, en dan later upgraden naar een Z2 Maar helaas, Ik had dat al even onderzocht, maar het is niet mogelijk om van RAIDZ1 naar RAIDZ2 te converteren

[ Voor 4% gewijzigd door F-Tim op 14-09-2015 13:42 ]

[DaCoTa]

F-Tim schreef op maandag 14 september 2015 @ 13:40:
[...]


Eigenlijk lijkt me dit ook wel een prima startpad... lange termijn wél een volledige 2 disk redundancy. Hoewel het initieel het nadeel van minder beschikbare ruimte, vond ik het lange termijn voordeel beter (en voordat ik aan de 12TB kwam zou toch nog wel ff duren)

Enige wat ik als "klein" probleem voorzie bij bovenstaand pad, is dat bij de initialisatie van het array alles geformatteeerd wordt. Met als gevolg, dat ik hierbij het array eigenlijk niet kan initialiseren zonder dataverlies. De 8TB kan ik niet zomaar elders parkeren, ik denk dat ik met goed m'n best doen op ongeveer 4TB aan flex-storage ga komen, maar dan verlies ik dus alsnog 4TB data. Of zie ik het nu verkeerd?

Als oplossing daarvoor bedacht ik een extra 4TB te kopen, maar dan koop ik alsnog 3x 4TB... dus ik denk, dan meteen met 5x 4TB Z1 starten, en dan later upgraden naar een Z2 Maar helaas, Ik had dat al even onderzocht, maar het is niet mogelijk om van RAIDZ1 naar RAIDZ2 te converteren

Dat kan wel, maar dat is wat gepuzzel. Je kan een Z2 aanmaken met memory disks en die meteen offline halen. Een beetje torens van Hanoi spelen, maar ik heb de migratie naar de pool gedaan zonder extra disks.

Ik had wel een overloop pool gemaakt op de grotere schijven om de data tijdelijk op te parkeren zodat de kleinere disks vrij zouden komen. Je moet je scenario even uitschrijven, maar het zou moeten lukken, want je hebt maar 4 disks nodig om een sparse Z2 te maken, en over die 4 disks moet je 8TB parkeren. Naast die 8TB is er dus nog genoeg netto ruimte voor tijdelijke pools om te kunnen schuiven.

Dit spelletje heeft mij overigens wel een paar dagen gekost, voordat alle data op de uiteindelijk pool stond :-)

Je kan natuurlijk die tijdelijke pools ook met parity maken, dan ben je al wat veiliger.

[F-Tim]

DaCoTa schreef op maandag 14 september 2015 @ 13:45:
[...]

Dat kan wel, maar dat is wat gepuzzel. Je kan een Z2 aanmaken met memory disks en die meteen offline halen. Een beetje torens van Hanoi spelen, maar ik heb de migratie naar de pool gedaan zonder extra disks.

Ik had wel een overloop pool gemaakt op de grotere schijven om de data tijdelijk op te parkeren zodat de kleinere disks vrij zouden komen. Je moet je scenario even uitschrijven, maar het zou moeten lukken, want je hebt maar 4 disks nodig om een sparse Z2 te maken, en over die 4 disks moet je 8TB parkeren. Naast die 8TB is er dus nog genoeg netto ruimte voor tijdelijke pools om te kunnen schuiven.

Dit spelletje heeft mij overigens wel een paar dagen gekost, voordat alle data op de uiteindelijk pool stond :-)

Je kan natuurlijk die tijdelijke pools ook met parity maken, dan ben je al wat veiliger.

Als ik je dan dus goed begrijp zou ik dus ook een RAID Z2 met 5x 4TB en 1 memory disk kunnen starten? Waarbij de 2de parity "offline" is, en ik die dan 'later' online kan krijgen? Dan start je met een soort van fake Z1 onder een Z2 vlag.... of kan dát weer niet (Of werkt het resilveren niet als 1 disk offline is, want dan heb k er natuurlijk niks aan...)

[DaCoTa]

F-Tim schreef op maandag 14 september 2015 @ 13:50:
[...]
Als ik je dan dus goed begrijp zou ik dus ook een RAID Z2 met 5x 4TB en 1 memory disk kunnen starten? Waarbij de 2de parity "offline" is, en ik die dan 'later' online kan krijgen? Dan start je met een soort van fake Z1 onder een Z2 vlag.... of kan dát weer niet (Of werkt het resilveren niet als 1 disk offline is, want dan heb k er natuurlijk niks aan...)

Ja, dat kan, ik heb het initieel met 2 offline disks gedaan. Staat ergens (OP?) een guide hoe dat te doen, maar ik denk dat CiPHER dat precies weet :-)

[EnerQi]

F-Tim schreef op maandag 14 september 2015 @ 13:50:
[...]


Als ik je dan dus goed begrijp zou ik dus ook een RAID Z2 met 5x 4TB en 1 memory disk kunnen starten? Waarbij de 2de parity "offline" is, en ik die dan 'later' online kan krijgen? Dan start je met een soort van fake Z1 onder een Z2 vlag.... of kan dát weer niet (Of werkt het resilveren niet als 1 disk offline is, want dan heb k er natuurlijk niks aan...)

Je hebt het door. RAIDZ2 maken met 6 schijven (5 echte, 1 memory), reboot en je hebt nog steeds 1 schijf bescherming. Vervolgens na datacopy de ontbrekende schijf toevoegen.

[syl765]

Ja dat klopt, je kan een zpool maken met memdisks en deze dan direct offline halen. Let wel je ZPOOL staat direct in DEGRADE mode.
Daarna kun je gewoon de pool gebruiken en later de twee missende disken resilveren.
Vergeet niet je memdisks te verwijderen en los te koppelen na het maken van de zpool

Onderstaand een voorbeeld hoe dit te doen.
(TEST even op een ander systeem als je dit tot je beschikking hebt.)

Plaats disk 1, gpart de disk
#gpart create -s GPT /dev/ada0
#gpart create -a 4k -t freebsd-zfs -l disk-ada0 /dev/ada0
Plaats disk 2, gpart de disk
#gpart create -s GPT /dev/ada1
#gpart create -a 4k -t freebsd-zfs -l disk-ada1 /dev/ada1

#mdconfig -a -t malloc -s 4T
#md0
#mdconfig -a -t malloc -s 4T
#md1
# zpool create newpool raidz2 /gpt/disk-ada0 /gpt/disk-ada1 /dev/md0 /dev/md1
# zpool offline newpool md0
# zpool offline newpool md1
# mdconfig -d -u 0
# mdconfig -d -u 1

[F-Tim]

EnerQi schreef op maandag 14 september 2015 @ 13:53:
[...]


Je hebt het door. RAIDZ2 maken met 6 schijven (5 echte, 1 memory), reboot en je hebt nog steeds 1 schijf bescherming. Vervolgens na datacopy de ontbrekende schijf toevoegen.

Ik snap het semi, want wat ik dan wil doen is starten met die 5 echte en 1 memory... en dan na X tijd, zeg bv 3 maanden de laatste memory disk replacen door een echte disk. Zodra tussentijds dan 1 van de echte schijven crasht moet ik deze uiteraard vervangen, ik vraag me dan daarbij wel af of ik het gehele array compleet moet hebben of dat je met 5/1 ook al een resilver kunt doen?

syl765 schreef op maandag 14 september 2015 @ 14:00:
Ja dat klopt, je kan een zpool maken met memdisks en deze dan direct offline halen. Let wel je ZPOOL staat direct in DEGRADE mode.
Daarna kun je gewoon de pool gebruiken en later de twee missende disken resilveren.
Vergeet niet je memdisks te verwijderen en los te koppelen na het maken van de zpool

Onderstaand een voorbeeld hoe dit te doen.
(TEST even op een ander systeem als je dit tot je beschikking hebt.)

Plaats disk 1, gpart de disk
#gpart create -s GPT /dev/ada0
#gpart create -a 4k -t freebsd-zfs -l disk-ada0 /dev/ada0
Plaats disk 2, gpart de disk
#gpart create -s GPT /dev/ada1
#gpart create -a 4k -t freebsd-zfs -l disk-ada1 /dev/ada1

#mdconfig -a -t malloc -s 4T
#md0
#mdconfig -a -t malloc -s 4T
#md1
# zpool create newpool raidz2 /gpt/disk-ada0 /gpt/disk-ada1 /dev/md0 /dev/md1
# zpool offline newpool md0
# zpool offline newpool md1
# mdconfig -d -u 0
# mdconfig -d -u 1

Ik heb weliswaar niks liggen, maar dit zou ook moeten kunnen met een VM en dan met virtuele schijven van 1GB. Dat moet de "generale repetitie" worden alvorens ik met de echte disks ga werken straks

[ Voor 47% gewijzigd door F-Tim op 14-09-2015 14:07 ]

[EnerQi]

F-Tim schreef op maandag 14 september 2015 @ 14:05:
[...]


Ik snap het semi, want wat ik dan wil doen is starten met die 5 echte en 1 memory... en dan na X tijd, zeg bv 3 maanden de laatste memory disk replacen door een echte disk. Zodra tussentijds dan 1 van de echte schijven crasht moet ik deze uiteraard vervangen, ik vraag me dan daarbij wel af of ik het gehele array compleet moet hebben of dat je met 5/1 ook al een resilver kunt doen?

Memory disk mag je niet gebruiken. Zoals de naam het aangeeft, gebruik je je RAM geheugen en 4TB RAM geheugen heb jij niet in je PC/NAS .

Je kunt met RAIDZ2: 4 schijven en 2 fails nog steeds een volledige resilvering doen. Er vanuit gaat dan de overige schijven geen fouten bevatten

[DaCoTa]

F-Tim schreef op maandag 14 september 2015 @ 14:05:
Ik snap het semi, want wat ik dan wil doen is starten met die 5 echte en 1 memory... en dan na X tijd, zeg bv 3 maanden de laatste memory disk replacen door een echte disk. Zodra tussentijds dan 1 van de echte schijven crasht moet ik deze uiteraard vervangen, ik vraag me dan daarbij wel af of ik het gehele array compleet moet hebben of dat je met 5/1 ook al een resilver kunt doen?

Je resilvert een disk, niet een pool, dus je kan dat idd per disk doen.

[HyperBart]

F-Tim schreef op maandag 14 september 2015 @ 14:05:
[...]


Ik snap het semi, want wat ik dan wil doen is starten met die 5 echte en 1 memory... en dan na X tijd, zeg bv 3 maanden de laatste memory disk replacen door een echte disk. Zodra tussentijds dan 1 van de echte schijven crasht moet ik deze uiteraard vervangen, ik vraag me dan daarbij wel af of ik het gehele array compleet moet hebben of dat je met 5/1 ook al een resilver kunt doen?


[...]


Ik heb weliswaar niks liggen, maar dit zou ook moeten kunnen met een VM en dan met virtuele schijven van 1GB. Dat moet de "generale repetitie" worden alvorens ik met de echte disks ga werken straks

Zo heb ik het ook gedaan, gaat prima en ik heb nooit minder dan 1 disk tbv redundantie gehad:
HyperBart in "Het grote ZFS topic"

Wel in acht houden, zoals men hierboven al zei, dat een memory disk niet meer is dan een placeholdertje, maar dat je die zo snel mogelijk offline moet gooien, anders loopt je geheugen vol en knalt dat device er toch uit omdat er geen I/O meer naar gestuurd kan worden...

[ Voor 13% gewijzigd door HyperBart op 14-09-2015 14:24 ]

[Loekie]

Hoe meer ik met ZFS bezig ben hoe minder ik er van lijk te begrijpen. Ik heb nu een mooie array opgebouwd met 8*6TB op een systeem met 12GB geheugen en heb ik testen al wel redelijke resultaten, maar zie dat er verschillende features zijn die voor mijn use case interessant kunnen zijn.
Use case is vnl Movies en series, wat muziek en backups van verschillende machines, dit in zowel gecomprimeerd als ongecomprimeerde vorm en beelden van securitycams en wat opslag in vorm van ISO's.
Huidige features zijn als volgt en lees Active als daadwerkelijk in gebruik, enabled als mogelijk en disabled niet in gebruik.
Welke features kan ik het best op pool inschakelen en welke best op filesystem?

code:

Enabled     async_destroy   Destroy filesystems asynchronously.     
Active      empty_bpobj     Snapshots use less space.   
Active      lz4_compress    LZ4 compression algorithm support.  
Disabled    multi_vdev_crash_dump   Crash dumps to multiple vdev pools.     
Disabled    spacemap_histogram  Spacemaps maintain space histograms.    
Disabled    enabled_txg     Record txg at which a feature is enabled    
Disabled    hole_birth  Retain hole birth txg for more precise zfs send     
Enabled     extensible_dataset  Enhanced dataset functionality, used by other features.     
Disabled    embedded_data   Blocks which compress very well use even less space.    
Disabled    bookmarks   "zfs bookmark" command  
Disabled    filesystem_limits   Filesystem and snapshot limits.     
Enabled     large_blocks    Support for blocks larger than 128KB.

[Verwijderd]

lz4_compress en large_blocks is het meest interessant. Daarna misschien embedded_data wat een klein beetje ruimte en performance toevoegt als je veel kleine files hebt die goed comprimeerbaar zijn. Verder niet zo heel interessante features eigenlijk... Het beste zit al in ZFS zelf (tot versie 28).

ZFS is van versie 1 naar 28 gegaan, en daarna naar versie 5000 met aparte feature flags. Wat je nu copy-pasted zijn dus die feature flags.

[CurlyMo]

Linkjes naar de uitleg post over feature flags kan je vinden in de TS.

[FireDrunk]

Open-ZFS.org heeft de talks bekend gemaakt voor de Dev Summit:

http://open-zfs.org/wiki/OpenZFS_Developer_Summit_2015

Zmotion, Persistant L2ARC, Compressed ARC... Klinkt allemaal erg tof

[Q]

Fun!

Met persistent L2ARC krijg je al een beetje tiering.
Maar ik mis nog de 3-laags tiering. 1. SSD 2. Snelle disks 3.trage archival disks.

[ Voor 26% gewijzigd door Q op 15-09-2015 10:47 ]

[CurlyMo]

Het zou mooi zijn als je persistent ARC zou hebben. Dus dat voor een reboot de ARC in een swap file zou worden gezet net als bij hibernation wat na het booten weer in het geheugen zou worden ingeladen.

[FireDrunk]

Q schreef op dinsdag 15 september 2015 @ 10:46:
Fun!

Met persistent L2ARC krijg je al een beetje tiering.
Maar ik mis nog de 3-laags tiering. 1. SSD 2. Snelle disks 3.trage archival disks.

Lessfs, BTIER, LVMTS?

[DXaroth]

Q schreef op dinsdag 15 september 2015 @ 10:46:
Fun!

Met persistent L2ARC krijg je al een beetje tiering.
Maar ik mis nog de 3-laags tiering. 1. SSD 2. Snelle disks 3.trage archival disks.

1: ARC
2: L2ARC
3: Storage

of mis ik nu wat?

[FireDrunk]

Mja, das niet hetzelfde als wat hij bedoeld, maar 3 tiers is een beetje nutteloos in mijn ogen.
L2ARC kan je zo groot maken als je zelf wil, en zelfs met meerdere schijven.

[riwi]

Je L2ARC moet je ook niet te groot maken want dat kost je weer veel geheugen.

Maar persistent L2ARC zou wel mooi zijn omdat de meeste thuisgebruikers hun NAS toch wel regelmatig uit zetten.

[FireDrunk]

In elke tiering oplossing heb je dat nodig. Als de lookups om te kijken *waar* de data staat, langer duren dan de data zelf ophalen, schiet je jezelf in je poten

[Q]

FireDrunk schreef op dinsdag 15 september 2015 @ 11:26:
[...]


Lessfs, BTIER, LVMTS?

Spuug, plakband en 2e hands ductape?



Daar ga ik mijn SAN niet op baseren

Ik ga er voor de lol nog wel eens mee spelen (btier) want het is best gaaf.

FireDrunk schreef op dinsdag 15 september 2015 @ 12:16:
Mja, das niet hetzelfde als wat hij bedoeld, maar 3 tiers is een beetje nutteloos in mijn ogen.
L2ARC kan je zo groot maken als je zelf wil, en zelfs met meerdere schijven.

Wat is dan de reden dan dat alle serieuze SANs dit 3-tier model ondersteunen?

Waarom niet gewoon SSD-only gaan en je l2arc weg smijten?

[ Voor 40% gewijzigd door Q op 15-09-2015 12:45 ]

[FireDrunk]

Ik ken weinig implementaties die dat online doen. Offline (of near-line, hoe je het wil noemen) tiering gebeurt veel meer.

Ik heb persoonlijk nog weinig implementaties gezien die realtime meerdere tiers ondersteunen zonder veel geheugen nodig te hebben, *en* die een goede prestatie verhouding weten te behouden in the long run...

Maar goed: Ik weet ook niet alles, dus misschien moet ik gewoon nog op een leuk stukje software (of hardware) gewezen worden

[ Voor 16% gewijzigd door FireDrunk op 15-09-2015 12:52 ]

[Bigs]

DXaroth schreef op dinsdag 15 september 2015 @ 12:06:
[...]


1: ARC
2: L2ARC
3: Storage

of mis ik nu wat?

ARC = cache, dat is iets anders dan tiering.

@FireDrunk: 3-tier systemen zijn toch wel gemeengoed geworden volgens mij en dit heeft ook zeker nut in grote opslagsystemen. Je gearchiveerde data staat lekker op NL-SAS schijven, de dagelijkse data op snellere SAS schijven en de OLTP workloads etc. op SSD. Je gooit gewoon alles op je SAN en hebt er geen omkijken naar. Bij de meeste systemen gebeurt dit ook gewoon continu in de achtergrond, zowel inter-tier migraties als intra-tier migraties (als je bijvoorbeeld 10 RAID arrays op je SAS tier hebt waarvan er 1 naar verhouding veel drukker is dan de rest). Dit gaat over het algemeen wel in een grote block size (>100MB en soms zelfs >1GB), vandaar dat het ook eenvoudig live bij te houden is.

[ Voor 26% gewijzigd door Bigs op 15-09-2015 15:26 ]

[DaCoTa]

Ik heb bij tijd en wijlen - om de zoveel maanden - dat er een van mijn disks uit mijn pool valt. In de logs staat er:

code:

Sep 12 08:51:57 zfsguru kernel: ada2 at ahcich2 bus 0 scbus2 target 0 lun 0
Sep 12 08:51:57 zfsguru kernel: ada2: <WDC WD20EADS-00W4B0 01.00A01> s/n WD-WCAVY5437730 detached
Sep 12 08:51:57 zfsguru kernel: (ada2:ahcich2:0:0:0): Periph destroyed
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): CAM status: ATA Status Error
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retries exhausted
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): CAM status: ATA Status Error
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): Error 5, Retries exhausted
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): CAM status: ATA Status Error
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Sep 12 08:52:04 zfsguru kernel: (aprobe1:ahcich2:0:15:0): Error 5, Retries exhausted
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): CAM status: ATA Status Error
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Sep 12 08:52:04 zfsguru kernel: (aprobe0:ahcich2:0:0:0): Error 5, Retries exhausted

Het is altijd dezelfde disk, een bijna 4 jaar oude WD20EADS waar ik nooit de idle timeout goed gezet heb, dus hij staat inmiddels op 307969 load cycles. Kan het zijn dat de disk het zelf opgeeft en zichzelf disconnect? Na een reboot is de disk weer terug en een automatische resilver later is de pool weer compleet.

Smart van die disk:

#	SMART attribute	Flag	Current	Worst	Threshold	Failed	RAW value
1	Raw_Read_Error_Rate	0x002f	200	200	051	-	0
3	Spin_Up_Time	0x0027	253	227	021	-	8200
4	Start_Stop_Count	0x0032	100	100	000	-	161
5	Reallocated_Sector_Ct	0x0033	200	200	140	-	0
7	Seek_Error_Rate	0x002e	200	200	000	-	0
9	Power_On_Hours	0x0032	057	057	000	-	31633
10	Spin_Retry_Count	0x0032	100	100	000	-	0
11	Calibration_Retry_Count	0x0032	100	253	000	-	0
12	Power_Cycle_Count	0x0032	100	100	000	-	95
192	Power-Off_Retract_Count	0x0032	200	200	000	-	47
193	Load_Cycle_Count	0x0032	098	098	000	-	307972
194	Temperature_Celsius	0x0022	120	100	000	-	32
196	Reallocated_Event_Count	0x0032	200	200	000	-	0
197	Current_Pending_Sector	0x0032	200	200	000	-	0
198	Offline_Uncorrectable	0x0030	200	200	000	-	0
199	UDMA_CRC_Error_Count	0x0032	200	200	000	-	0
200	Multi_Zone_Error_Rate	0x0008	200	200	000	-	0

Faulty cable?

[ Voor 30% gewijzigd door DaCoTa op 15-09-2015 15:33 ]

[Verwijderd]

Disks disconnecten zich niet. Dat doet je OS 'detached' en 'Periph destroyed'.

Begin eens met de SMART, zoals altijd.

Kabel kan nog steeds, ondanks dat je UDMA CRC Error Count op 0 staat. Maar om het wat breder te maken: welke controller? Marvell controller zou je gedrag kunnen verklaren.

[ Voor 41% gewijzigd door Verwijderd op 15-09-2015 15:47 ]

[Q]

FireDrunk schreef op dinsdag 15 september 2015 @ 12:52:
Ik ken weinig implementaties die dat online doen.
Maar goed: Ik weet ook niet alles, dus misschien moet ik gewoon nog op een leuk stukje software (of hardware) gewezen worden

Zover ik weet is er niets open-source. HP 3par en al dat soort enterprise style producten doen al langer weldegelijk aan 3-tier storage met dan nog RAM als cache/buffer. volgens mij doet veel EMC spul het ook.

[FireDrunk]

Zoals ik al zei: Ik ken geen implementaties die niet geheugen hongerig zijn, en toch top tier inline tiering doen.

Uiteraard zijn ze er wel, maar dan heeft je head unit vaak > 32GB geheugen, of gaat het asynchroon.

[DaCoTa]

Verwijderd schreef op dinsdag 15 september 2015 @ 15:28:
Kabel kan nog steeds, ondanks dat je UDMA CRC Error Count op 0 staat. Maar om het wat breder te maken: welke controller? Marvell controller zou je gedrag kunnen verklaren.

Oh ja, ik heb wel 3 checksum errors gereset, vandaar dat die op 0 staat.

Controller is AMD A85X chipset, alle disks zitten op de onboard controller (MSI FM2-A85XA-G65).

code:

ahci0: <AMD Hudson-2 AHCI SATA controller> port 0xf140-0xf147,0xf130-0xf133,0xf120-0xf127,0xf110-0xf113,0xf100-0xf10f mem 0xfeb4d000-0xfeb4d7ff irq 19 at device 17.0 on pci0
ahci0: AHCI v1.30 with 7 6Gbps ports, Port Multiplier supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich3: <AHCI channel> at channel 3 on ahci0
ahcich4: <AHCI channel> at channel 4 on ahci0
ahcich5: <AHCI channel> at channel 5 on ahci0
ahcich6: <AHCI channel> at channel 6 on ahci0

Channel 0 is de OS disk.

Ik zal eens een handvol nieuwe kabels halen en ze allemaal vervangen. Het is een Z2 pool, dus 1 disk minder is geen probleem maar is gewoon gedoe.

[ Voor 46% gewijzigd door DaCoTa op 15-09-2015 20:02 ]

[Verwijderd]

Je kunt SMART data niet resetten. Wat jij bedoelt is dat je de zpool status output hebt gereset met zpool clear. Dat heeft echter niets met de SMART te maken.

[maomanna]

ik heb mijn zpool compleet geexporteerd vanuit zfsguru en daarna geimporteerd in ubuntu server.

Nu zit de L2ARC in de weg.
Ik heb een nieuwe cache toegevoegd, die wordt geaccepteerd, maar de oude krijg ik niet meer weg.

code:

root@centraalpunt:/# zpool status ZFSBulk
  pool: ZFSBulk
 state: ONLINE
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: none requested
config:
 
        NAME        STATE     READ WRITE CKSUM
        ZFSBulk     ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0
        logs
          sdd3      ONLINE       0     0     0
        cache
          L2ARC     UNAVAIL      0     0     0
          sdd4      ONLINE       0     0     0
 
errors: No known data errors
root@centraalpunt:/# zpool remove ZFSBulk L2ARC
cannot remove L2ARC: no such device in pool

Replace werkt ook niet

code:

root@centraalpunt:/# zpool replace ZFSBulk L2ARC sdd4
cannot replace L2ARC with sdd4: no such device in pool

van FireDrunk kreeg ik deze link: https://github.com/zfsonlinux/zfs/issues/1530

Daarin staat dat je de GUIP moet zoeken en zo moet verwijderen.

code:

root@centraalpunt:/# zpool remove ZFSBulk 7721001579302513491
root@centraalpunt:/# zpool status ZFSBulk                                         pool: ZFSBulk
 state: ONLINE
status: One or more devices could not be used because the label is missing or
        invalid.  Sufficient replicas exist for the pool to continue
        functioning in a degraded state.
action: Replace the device using 'zpool replace'.
   see: http://zfsonlinux.org/msg/ZFS-8000-4J
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        ZFSBulk     ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0
            sdh     ONLINE       0     0     0
        cache
          L2ARC     UNAVAIL      0     0     0
          sdd4      ONLINE       0     0     0

Zonder succes.


vanuit zpool history ZFSBulk de history opgezocht en de disk geprobeerd te verwijderen:

code:

root@centraalpunt:/# zpool remove ZFSBulk gpt/L2ARC
cannot remove gpt/L2ARC: no such device in pool

Hebben jullie nog ideeen?

[riwi]

maomanna schreef op vrijdag 18 september 2015 @ 11:11:
ik heb mijn zpool compleet geexporteerd vanuit zfsguru en daarna geimporteerd in ubuntu server.
Nu zit de L2ARC in de weg.
...
root@centraalpunt:/# zpool remove ZFSBulk L2ARC
cannot remove L2ARC: no such device in pool
[/code]

Ik heb daar ook mee gezeten en kreeg de L2ARC van de ZFS guru pool niet weg onder ZoL.
Volgens mij is dat een bug.
https://github.com/zfsonlinux/zfs/issues/1530


In ieder geval zou je ZFS guru weer kunnen pakken, pool importeren en daar je cache weg definieren. Dan vervolgens weer importeren onder ZoL.

Ik heb de data eraf gekopieerd en de pool opnieuw gebouwd met een andere layout (was 10x4T raidz2 en nu 13x4T raidz2 want dat wilde ik toch al).

[ Voor 35% gewijzigd door riwi op 18-09-2015 12:45 ]

[maomanna]

Dat kan ik simpel doen met een livecd van zfsguru. Dat scheelt me een hoop installeren etc.

https://github.com/zfsonlinux/zfs/pull/2012 zou ook een optie kunnen zijn, maar helaas werkt de zpool status -g niet

[ Voor 39% gewijzigd door maomanna op 18-09-2015 13:11 ]

[riwi]

maomanna schreef op vrijdag 18 september 2015 @ 13:10:
https://github.com/zfsonlinux/zfs/pull/2012 zou ook een optie kunnen zijn, maar helaas werkt de zpool status -g niet

Nee dan moet je eerst die pull request mergen met je lokale git en dan builden.
Maar ik doe dat eigenlijk nog niet omdat ik niet kan overzien welke pull requests met wat wel en niet compatible zijn. Ik hou me bij de main git repository van ZoL.
Dus voor deze status -g feature moet je dan wachten tot Brian Behlendorf deze pull request ge'commit' heeft.

[ Voor 3% gewijzigd door riwi op 18-09-2015 13:47 ]

[RobertMe]

RobertMe schreef op zondag 28 juni 2015 @ 19:47:
Ik heb een aantal jaartjes geleden een Linux (Arch Linux) systeem opgezet met ZFS on Linux. Op basis van een scrub blijkt nu echter dat een disk aan het failen is (ZFS geeft errors over beschadigde bestanden, uit verder onderzoek blijkt dat SMART o.a. bad sector allocations doorgeeft). Deze disk wil ik dus gaan vervangen, ik heb alleen geen idee hoe dit aan te pakken.

Een situatie schets:
SDD met Linux installatie
Seagate 3TB disk verdeelt in twee partities van 500GB en 2TB
WD 500GB disk

De volledige 500GB disk, en de 500GB partitie samen vormen via mirroring de "backup" pool. De 2TB partitie bevat vervolgens een "storage" pool. De failende pool in deze is vervolgens de "storage" pool, en de failende disk is dus de 3TB Seagate.

[...]

Voor zover ik met mijn zeer beperkte ZFS kennis weet zou ik in dit geval een nieuwe disk kunnen plaatsen, deze hetzelfde partitioneren, en met zpool replace de failende partitie van de "backup" pool kunnen over zetten. Echter heb ik een vermoeden dat dit voor de "storage" pool niet mogelijk is, omdat deze maar op een enkele disk draait.

Om hier nog even op terug te komen. Op jullie advies heb ik toentertijd de bestaande pools uitgebreid met de nieuwe disk, waardoor ik een "backup" pool had met 3 disks in mirror en een "storage" pool met 2 disks in mirror. Echter is nu de disk met bad sectors helemaal overleden (maakte eerst een raar, zoemend/snirkend, geluid, alsof die niet meer wou draaien, en na een reboot wordt deze niet eens meer herkend).

Echter zit ik nu met een nieuw (nog groter?) probleem. Toentertijd heb ik de nieuw disk gepartitioneerd en opgenomen in de zpool op basis van /dev/disk/by-id/. Dit omdat ik dacht dat ik daarmee een "vaste" naam zou hebben (de anderen zijn nog op basis van /dev/sdXY, die sowieso veranderen bij opnieuw/anders aansluiten). Echter is dit niet het geval, de id entries zijn veranderd en ZFS herkent nu ook de nieuwe disk niet meer.

Dit is nu de huidige situatie volgens zpool status

pool: backup
state: DEGRADED
status: One or more devices could not be used because the label is missing or
invalid. Sufficient replicas exist for the pool to continue
functioning in a degraded state.
action: Replace the device using 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
scan: scrub repaired 0 in 3h14m with 0 errors on Sun Aug 16 22:52:42 2015
config:

NAME STATE READ WRITE CKSUM
backup DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sdb1 ONLINE 0 0 0
6631667374241741865 FAULTED 0 0 0 was /dev/sdc2
467942269610378806 UNAVAIL 0 0 0 was /dev/disk/by-id/wwn-0x11197650611592122369x-part1

errors: No known data errors

Dit lijkt mij dus aan te geven dat, in ieder geval in eerste instantie /dev/sdc2 naar "FAULTED" is gegaan op het moment dat de disk stuk is gegaan (niet meer leesbaar was). Vervolgens zal na de reboot het id zijn veranderd van de nieuwe disk, waardoor deze naar "UNAVAIL" is gegaan? Daarnaast valt het op dat de "storage" pool hier volledig in ontbreekt (want staat op een stukke disk die helemaal niks meer doet, en een disk die van id is veranderd).

Informatie m.b.t. disk layout
/dev/sda: niet relevante boot disk met ext4
/dev/sdb: de nog enige werkende disk uit de backup pool. Deze zit al sinds installatie van het systeem in de pool
/dev/sdc: dit was de oude disk, waarbij partitie 1 de storage pool vormde, en partitie 2 de mirror uit de backup pool. Op het moment is dit de nieuwe disk, waarbij, lekker verwarrend, partitie 1 de mirror uit de backup pool is en partitie 2 de storage pool vormd(e, mirror samen met de nu stukke disk).

De nieuwe disk uit de backup pool verwees dus naar /dev/disk/by-id/wwn-0x11197650611592122369x-part1, dit is nu wwn-0x50014ee20be79b66-part1.

Daarnaast heb ik al bevestigd dat ZFS de storage pool wel nog herkent om te importeren:

sudo zpool import
pool: storage
id: 15089917995132482713
state: DEGRADED
status: One or more devices contains corrupted data.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
config:

storage DEGRADED
mirror-0 DEGRADED
sdc1 UNAVAIL corrupted data
sdc2 ONLINE

Waarbij ik dit lees als: sdc2 is nu gevonden en bevat een werkende pool, met de naam "storage". Waarbij dus de pool van de nieuwe, werkende, disk wordt gelezen. Deze werkende pool bevat vervolgens informatie dat het een mirror is met "sdc1", echter is dat intussen een andere disk (was de oude disk, die nu stuk is, en is nu de nieuwe werkende disk waarbij de backup mirror op de eerste partitie, dus sdc1, staat), en daardoor als "UNAVAIL corrupted data" wordt gemarkeerd.

Mijn concrete vraag is nu:
Hoe krijg ik dit weer allemaal goed aan de praat? Liefst op een zo efficiënt mogelijke manier (bestaande partities opnieuw "aankoppelen" onder hun nieuwe locatie). Wat mij mogelijk lijkt, is de FAULTED en UNAVAIL disk uit de "backup" pool verwijderen (zpool detach backup sdc2; zpool detach backup wwn-0x11197650611592122369x-part1), en daarna opnieuw sdc1 aankoppelen aan de backup mirror (zpool attach backup sdb1 sdc1). Vervolgens kan ik dan ook de "storage" pool opnieuw importeren (zpool import storage), en daarna de sdc1 entry daaruit halen. Alleen denk ik dat dit niet ideaal is, omdat ik verwacht dat het detachen en attachechen van de partitie aan de "backup" pool de mirror volledig opnieuw gaat opbouwen? Terwijl de mirror/data nog (vrijwel) gelijk is.

Daarnaast nog de vraag wat dus wel werkt om altijd gelijke device names te hebben. Ik dacht dat dat het geval zou zijn met het gebruik van de by-id namen, maar dat blijkt dus niet te kloppen. En daarbij dan ook meteen de vraag of het mogelijk is om alle pools opnieuw "op te bouwen" gebruik makende van deze persistente namen. Zodat ik niet dus nog eens een keer voor onverwachte problemen kom te staan als een disk uitvalt.

Alvast bedankt voor jullie antwoord

[Verwijderd]

Ojee ojee, dit is dus één van de redenen waarom ik geen ZoL zal aanraden.

Maar boot eventjes in BSD omgeving en fix daar je pool. Dan weer terugswitchen naar ZoL.

[RobertMe]

Kan dat dan op een directe manier? Want volgensmij zit het grootste probleem dan in de "koppeling" naar welke pools uit welke partities bestaat. En dat is dan iets waar BSD weer heel anders mee om gaat (andere device names).

En ik gok dat ik dan vanaf een LiveCD (/USB) moet booten en dan een import doen van de pools? En daarna weer onder de normale installatie (met ZoL) importeren? Maar kan ik dan dus niet net zo goed de bestaande, maar niet gedetecteerde, storage pool importeren in ZoL?

Of is *BSD daarbij wel slim genoeg om te zien dat de partities zijn "verschoven" (andere partitie, waarop wel een pool met dezelfde naam staat), waardoor die dat (automatisch) kan corrigeren? En daardoor dus een stuk makkelijker is om de boel weer op de rails te krijgen. Want met mijn Google searches kwam ik niet verder dan de door mij omschreven (mogelijke) oplossing. En daarbij heb ik dus gewoon op ZFS dingen gezocht, niet specifiek naar ZoL (meeste hits waren dan ook de documentatie van Solaris).

[Verwijderd]

BSD heeft - in tegenstelling tot Solaris en Linux - een goede storage infrastructuur (GEOM) met 'device tasting'. Dat betekent: elke disk wordt bij elke boot geproeft wat daar precies op staat. Nog beter, het geldt niet voor elke disk, maar voor iedere GEOM-node. Partities zijn GEOM nodes, encrypted versies zijn GEOM nodes. Alles is een GEOM node.

Dat betekent dat, hoe je de disk ook aansluit, op welke controller dan ook en hoe je de disk ook hebt geconfigureerd, op elk moment BSD de juiste partitie/disk/whatever zal vinden wat bij welke ZFS pool hoort. Dat is wat je wilt. Andere besturingssystemen werken met een zielige zpool.cache file waar hardcoded staat opgeslagen wat waar hoort. En dan gaat het mis en kun je een typische 'corrupted data' melding krijgen omdat het operating system ZFS disks/partities geeft waar niet de juiste ZFS data staat. Dan houdt ZFS het voor gezien. Het operating system geeft de disks/partities door aan ZFS. ZFS zelf doet daar niets mee. Daarom zijn er dus ook verschillen tussen besturingssystemen.

Ik raad je aan nu niets meer te doen met Linux, maar eerst in BSD te booten en daar je pool(s) op orde krijgen. Pas als die helemaal ONLINE enzo zijn weer naar Linux gaan - waarbij je zorgt dat deze je pools niet automatisch probeert te mounten. Dus een verse installatie of je verwijdert de zpool.cache of wat dan ook. Dat je opnieuw je pools importeert op Linux en dan zou het allemaal moeten werken.

Ik raad je aan om een ZFSguru LiveCD of USB-stick te gebruiken. Dat is namelijk wat ik ken en ik kan je via DM helpen met de details. Zodra je je pool op orde hebt, kun je dan weer aan ZoL wagen.

[RobertMe]

Duidelijk, dank. Ik ga dit zondag meteen uitproberen en zal je dan een DM sturen als ik er zelf niet uit kom.

[Verwijderd]

Prima, en vooral doen dat DM want als je iets verkeerds doet ga je spijt krijgen dat je niet even bevestiging hebt gevraagd.

[FireDrunk]

Verwijderd schreef op vrijdag 18 september 2015 @ 22:17:
BSD heeft - in tegenstelling tot Solaris en Linux - een goede storage infrastructuur (GEOM) met 'device tasting'. Dat betekent: elke disk wordt bij elke boot geproeft wat daar precies op staat. Nog beter, het geldt niet voor elke disk, maar voor iedere GEOM-node. Partities zijn GEOM nodes, encrypted versies zijn GEOM nodes. Alles is een GEOM node.

Dat betekent dat, hoe je de disk ook aansluit, op welke controller dan ook en hoe je de disk ook hebt geconfigureerd, op elk moment BSD de juiste partitie/disk/whatever zal vinden wat bij welke ZFS pool hoort. Dat is wat je wilt. Andere besturingssystemen werken met een zielige zpool.cache file waar hardcoded staat opgeslagen wat waar hoort. En dan gaat het mis en kun je een typische 'corrupted data' melding krijgen omdat het operating system ZFS disks/partities geeft waar niet de juiste ZFS data staat. Dan houdt ZFS het voor gezien. Het operating system geeft de disks/partities door aan ZFS. ZFS zelf doet daar niets mee. Daarom zijn er dus ook verschillen tussen besturingssystemen.

Ik raad je aan nu niets meer te doen met Linux, maar eerst in BSD te booten en daar je pool(s) op orde krijgen. Pas als die helemaal ONLINE enzo zijn weer naar Linux gaan - waarbij je zorgt dat deze je pools niet automatisch probeert te mounten. Dus een verse installatie of je verwijdert de zpool.cache of wat dan ook. Dat je opnieuw je pools importeert op Linux en dan zou het allemaal moeten werken.

Ik raad je aan om een ZFSguru LiveCD of USB-stick te gebruiken. Dat is namelijk wat ik ken en ik kan je via DM helpen met de details. Zodra je je pool op orde hebt, kun je dan weer aan ZoL wagen.

Zucht... Echt waar, ik dacht dat ik kerkelijke dogma's ontvlucht was toen ik mij afsneed van de kerk, maar blijkbaar zit er hier nog 1...

1) Linux kent ook device tasting, en een automounter, en device nodes, en alles wat BSD ook heeft.
2) Als je ZFS by default laat, zal het de backwards compatibility van /dev gebruiken, en je devices geven met /dev/sda.
3) Als je keurig gebruik maakt van /dev/disk/by-id of /dev/disk/by-partlabel krijg je exact hetzelfde gedrag als onder BSD. Daar is niets anders aan.
4) BSD kent ook gewoon een zpool.cache? Die hoort bij ZFS... Dat is gewoon de lijst met reeds imported pools... niets meer en niets minder...
5) Je kan gewoon zpool export doen, daarna zpool import -d /dev/disk/by-id of /dev/disk/by-partlabel en kijk even wat ZFS er dan van maakt.

[Verwijderd]

Waarom krijgt hij dan 'corrupted data' te zien, als device tasting op Linux net zo zou werken als op BSD?

[DXaroth]

Verwijderd schreef op zaterdag 19 september 2015 @ 13:46:
Waarom krijgt hij dan 'corrupted data' te zien, als device tasting op Linux net zo zou werken als op BSD?

Hij had een disk op partitie-niveau toegevoegd aan zijn pool, als de partitie tabel prut raakt, raak je ook je partitie-indicator kwijt... dus dan blijft er enkel een wwn-<iets> over, maar gee wwn-<iets>-part1

[Verwijderd]

Dan zou die disk missing dus UNAVAIL moeten zijn, niet een disk/partitie met corrupted data. Dat gebeurt enkel als het OS een disk/partitie aan ZFS geeft waar niet de juiste data staat.

Een tijd terug hadden Firedrunk en ik deze discussie ook, en toen zei hij dat hij zelf zaken zou testen staat me bij. Totdat daar een uitslag van bekend is en ik dus mijn inzichten moet bijstellen, blijf ik erbij dat device tasting onder Linux niet werkt zoals zou moeten - zoals op BSD platform wel het geval is.

Als ik het mis heb, prima, maar volgens mij klopt het aardig wat ik zeg. En zo niet, ben ik niet te beroerd om FireDrunk een collectie heerlijke Belgische biertjes toe te zenden. Om zijn leed van kerkelijke dogma's te verzachten met Belgische Weelde.

[RobertMe]

FireDrunk, als ik het goed begrijp bedoel jij dus om de bestaande "backup" pool te exporteren, en daarna te importeren?

Als ik op het moment sudo zpool import -d /dev/disk/by-id/ doe krijg ik in ieder geval de volgende output:

pool: storage
id: 15089917995132482713
state: DEGRADED
status: One or more devices contains corrupted data.
action: The pool can be imported despite missing or damaged devices. The
fault tolerance of the pool may be compromised if imported.
see: http://zfsonlinux.org/msg/ZFS-8000-4J
config:

storage DEGRADED
mirror-0 DEGRADED
sdc1 UNAVAIL corrupted data
ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0VYJ8F8-part2 ONLINE

Maar dit is dus natuurlijk alleen de "storage" pool, die op het moment helemaal ontbreekt. Omdat de partitie die daar als "sdc1" staat dus de kapotte disk is, en die andere op basis van een ander id gekoppeld was.

Overigens viel mij ook net pas op dat er in de foutmelding van zpool status en zpool import ook nog een link staat, naar deze pagina: http://zfsonlinux.org/msg/ZFS-8000-4J/ . Hierop staat dus beschreven om de disks/partities te vervangen met zpool replace.

[RobertMe]

Op basis van FireDrunks reactie heb ik nu de boel weer goed aan de praat.

De "storage" pool heb ik geïmporteerd (zpool import -d /dev/disk/by-id storage) en daarna de missende partitie (van de defecte disk) gedetached.

Bij de "backup" pool heb ik eerst de missende partitie gedetached, en daarna geprobeerd om met zpool replace backup <nummer weergegeven in zpool status> <nieuwe id in disk/by-id> de "verplaatste" partitie weer aan de praat te krijgen. Echter werkte dat niet, met als reden dat die partitie al in gebruik was door pool "backup" (neem aan dus op basis van informatie die op de partitie zelf staat). Hierbij kon ik het replacen wel forceren maar daarbij verwachte ik dan ook een volledige resilver, dus heb ik niet gedaan. Op basis van FireDrunks reactie heb ik daarom de pool geëxporteerd (zpool export backup) en daarna opnieuw geïmporteerd (zpool import -d /dev/disk/by-id backup). Bij deze import zijn vervolgens ook netjes beide partities herkent. Alleen was er natuurlijk een error als resultaat, dat er een unrecoverable error is opgetreden. Dit lijkt mij dan te komen door het feit dat de ene partitie "voor loopt" op de andere partitie. Daarom heb ik nu een scrub gestart, omdat dat AFAIK normaliter de boel recht zou moeten trekken als er errors zijn geweest.

[FireDrunk]

Unrecoverable error zou vreemd zijn toch? De data zou uit replica's herstelbaar moeten zijn...
Vooral je ZFS disk structuur zal niet kapot mogen gaan, en een scrub zal dat soort dingen ook niet repareren. Een scrub gaat alleen maar om data, niet om structuur.

[RobertMe]

De structuur is nu weer in orde. Alleen is de data tussen beide disks uit de mirror uit sync gegaan. Dit omdat de boel dus wel (tijdelijk) heeft gedraaid met 1 werkende disk in backup pool. Die disk is toen dus aangepast, alleen is dat natuurlijk niet gebeurd voor de andere disk die toen niet correct herkend werd.

De scrub is intussen uit gelopen en de pool verkeert nu inderdaad nog steeds in error state:

pool: backup
state: ONLINE
status: One or more devices has experienced an unrecoverable error. An
attempt was made to correct the error. Applications are unaffected.
action: Determine if the device needs to be replaced, and clear the errors
using 'zpool clear' or replace the device with 'zpool replace'.
see: http://zfsonlinux.org/msg/ZFS-8000-9P
scan: scrub repaired 0 in 0h40m with 0 errors on Sun Sep 20 19:15:25 2015
config:

NAME STATE READ WRITE CKSUM
backup ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ata-WDC_WD5000AACS-00G8B1_WD-WCAUH0457848-part1 ONLINE 0 0 0
ata-WDC_WD40EZRX-00SPEB0_WD-WCC4E0VYJ8F8-part1 ONLINE 0 0 1

Lijkt mij dan toch dat de enige optie is om die laatste disk (die outdated is) helemaal te detachen en vervolgens opnieuw te attachen, zodat de mirror helemaal opnieuw wordt op gezet?

[Verwijderd]

Ja ZFS is ook zo onhandig met zijn meldingen. Unrecoverable voor de hardeschijf bedoelen ze - maar ZFS zelf heeft de fout wel recovered. Dat bedoelen ze met 'Applications are unaffected' - kortom ZFS heeft alles wel gefixed alleen de hardeschijf had data op een plek staan die onjuist was, om wat voor reden. Dit is helemaal niet zo ernstig als de foutmelding doet suggereren. Daar heb je immers ZFS voor.

Fijn dat je het hebt kunnen oplossen, trouwens!

[ Voor 5% gewijzigd door Verwijderd op 20-09-2015 19:57 ]

[RobertMe]

Maar ik zit nu dus wel nog met die status, en de "chksum" van 1 op een van die twee disks. Geeft dit nu puur aan dat er 1 error is geweest, of dat er 1 error is? En in het eerste geval, kan ik dat dan resetten? De oorzaak van de fout is immers bekend, en geld niet echt als een defect (van deze disk in ieder geval). In het Googlen heb ik in ieder geval "zpool clear" zien langskomen, is dat the way to go dan?

[CurlyMo]

1 CKSUM + State ONLINE is geweest.
1 CKSUM + State DEGRADED is op dit moment.

[Verwijderd]

zpool clear <poolnaam> en die irritante melding is weg. Dus dat kun je prima doen. Het verandert/doet verder niets, behalve de counters resetten. Die ene checksum error wordt dan weer gewoon 0.

[killercow]

Ik zit wat te stoeien met mn zfs omgeving.

Ik heb 11 disks in raidz3 draaien, aan een avaton machine, allemaal dikke prima. 2 ssd's als cache en zlog erbij, netjes mirrored.

Echter heb ik (ik gok omdat het seagate shingled disks betreft) nogal last van achterlijk hoge iowait tijden bij het schrijven van data naar de disks. Hierdoor schiet mn zfs resync process soms naar 100% cpu gebruik en loopt de io wait op mn server zo ver op dat eigenlijk alle transfers vanaf de pool compleet stoppen voor een aantal seconden.

Nu is dit allemaal niet een enorme ramp, maar een write naar de disks die zelfs het vloeiend streamen van een flac muziekje onmogelijk maakt is niet de deal natuurlijk.

Is er iets wat ik kan instellen dat ook kleine files zoals flacs geprefteched worden naar ssd/ram? Of iets waarbij ik de load vna het resync process kan limiteren? Zelfs alleen snachts syncen van ssd naar draaiend roest is prima gezien ik geen 60GB (de ssd ruimte) aan non-sequential writes ga maken elke dag.

Het gaat in het specifiek om het process 'txg_sync' op ubuntu server.

[ Voor 3% gewijzigd door killercow op 21-09-2015 20:37 ]

[Verwijderd]

Nee L2ARC werkt alleen voor non-contiguous I/O, dus niet voor sequential gelezen data zoals een FLAC.

Maar dit had je kunnen weten toch? Je koopt schijven waar iedereen voor waarschuwt, die duidelijk zijn bedoeld als archive dus alleen voor single-stream 100% sequential read en write, en jij gebruikt hem voor meerdere dingen tegelijk. Je L2ARC cache en sLOG hebben ook totaal geen zin - dan heb je echt de verkeerde schijven gekocht hiervoor. Je dient de schijven te gebruiken als een tapestreamer: honderden gigabytes schrijven of lezen en dan de schijven downspinnen, dat zou een goede workload zijn die past bij de eigenschappen van SMR-schijven.

txg_sync wil zeggen dat ZFS bezig is met het schrijven van een transaction group (txg). Dat duurt kennelijk heel lang, maar dit kan ook komen omdat je tussendoor allemaal dingen doet. Tsja...

[FireDrunk]

Nou nou nou. Dat is wel een heel snel oordeel.. Ja, SMR schijven zijn langzamer, maar ook weer niet *zo* langzaam... als hij 11 schijven in RAIDZ3 zet, zijn er genoeg spindles om een hoop te doen. Ja ZFS is niet zo super sterk in Random IO, maar als hij zowel SLOG als L2ARC heeft, zou ook dat geen probleem moeten zijn.

Misschien is het gewoon een keer handig om te debuggen waar je probleem zit.

Heb je al eens wat getuned aan ZFS? Want out of the box zijn L2ARC, SLOG en een grote RAIDZ3 array niet super snel...

Waar je aan kan denken bij tuning (in willekeurige volgorde):
- ARC Size
- VDEV Caching
- Maximale fillrate L2ARC
- maximale burst fillrate L2ARC
- Minimale / Maximale transactie grootte
- Minimale / Maximale transactie tijd
- (Als het gaat om Linux -> Moderne kernel? Disk readahead?)

Ik heb het regelmatig voor zien komen dat L2ARC je pool alleen maar langzamer maakte qua schrijven, omdat by default de L2ARC gelimiteerd wordt qua vul snelheid. Alles wat daarnaast er nog bij moest, ging bagger traag...

De fillrate heel hoog zetten zorgt er voor dat je vrij snel door je SSD heen (kan) branden.. Het is dus even raadzaam om daar goed naar te kijken.

[ Voor 18% gewijzigd door FireDrunk op 21-09-2015 22:19 ]

[Verwijderd]

Zijn L2ARC helpt niets tegen het feit dat hij tijdens sequential writes ook nog allemaal (sequential) reads doet. Dan moet de schijf tussendoor allemaal reads doen en dan heb je dus ipv sequential write allemaal kleine writes. Dat is gewoon enorm slecht en totaal niet waar de schijf voor bedoeld is. SMR schijven heb ik al vaker afgeraden, maar hebben nog wel een beoogd gebruiksdoel. Maar hoe killercow de schijven gebruikt, is niet waar ze voor zijn bedoeld. Dus de nadelen van de SMR-schijven worden dan ook extra uitvergroot.

Wat tuning aan ZFS met name de transaction groups zou zeker kunnen helpen. Zoals elke 1 of 2 seconde txg timeout of de write_limit wat kleiner zetten. Dus kleinere writes zodat de reads meer lucht krijgen. Maar ideaal is het niet. En zoals gezegd, de L2ARC heeft hij niet veel aan behalve voor het cachen van metadata zodat je die reads in elk geval niet hebt. De FLACs enzo lezen van een andere pool met normale hardeschijven of zelfs SSDs lijkt me een beter alternatief.

En je L2ARC wordt standaard gecapped op 8MiB/s dacht ik. Maar hoezo zou je pool daar langzamer van worden? Het duurt dan gewoon langer voordat je L2ARC cache is opgebouwd, maar ik zie niet waarom je pool zelf er langzamer van zou worden? De I/O tussendoor zou daar toch niet door vertraagd mogen worden?

[FireDrunk]

Volgens mij draait de L2ARC (trans)actie wel los van je gewone IO, maar ZFS remt volgens mij wel sequentiele transfers die 'qualified' zouden zijn om naar L2ARC te gaan. De precieze inner-workings van die daadwerkelijke offload acties ken ik niet, dat zou ik nog eens uit moeten diepen.

Ik heb ooit eens een bechmark gedraaid met en zonder L2ARC, en daar zag je echt *heel* duidelijk dat sequentiele writes enorm vertraagden als L2ARC aan stond.

[Verwijderd]

Oke dan is dat nieuw voor mij. In elk geval kan hij ook eens zonder L2ARC proberen. Dat is in het begin sowieso wel goed om eerst zonder te beginnen en pas later de L2ARC toe te voegen. Kun je ook qua gevoelssituatie ervaren in hoeverre het uitmaakt.

Zelf ben ik vooral fan van het cachen van alle metadata. Scheelt je weer een boel random reads die op grote RAID-Z's met vaak maar één of twee vdevs natuurlijk veel performance vreet.

[MikeVM]

Is het mogelijk om de nieuwste versies van plex te ondersteunen in zfsguru?
nu zit plex nog op 0.9.9.

manueel installeren zie ik niet echt zitten..

[maomanna]

Verwijderd schreef op maandag 21 september 2015 @ 22:59:

Zelf ben ik vooral fan van het cachen van alle metadata. Scheelt je weer een boel random reads die op grote RAID-Z's met vaak maar één of twee vdevs natuurlijk veel performance vreet.

Kan je zelf aangeven wat de L2ARC moet cachen?

[CurlyMo]

maomanna schreef op dinsdag 22 september 2015 @ 06:45:
[...]


Kan je zelf aangeven wat de L2ARC moet cachen?

Door de SSD niet als L2ARC toe te voegen aan je pool maar als eigen pool in te zetten en er zelf bestanden op te zetten

[Verwijderd]

MikeVM schreef op dinsdag 22 september 2015 @ 04:13:
Is het mogelijk om de nieuwste versies van plex te ondersteunen in zfsguru?
nu zit plex nog op 0.9.9.

manueel installeren zie ik niet echt zitten..

Plex zit nu op versie 0.9.12.11.1406 en die versie zit ook in ZFSguru build 004. Lijkt mij aardig up-to-date?

maomanna schreef op dinsdag 22 september 2015 @ 06:45:
Kan je zelf aangeven wat de L2ARC moet cachen?

Ja, je kan per filesystem opgeven wat er gecached moet worden met de primarycache en secondarycache attributen. Primary = RAM, Secondary = L2ARC dus de SSD. En je kunt instellen op All (data+metadata) of op Metadata. Met dat laatste wordt dus alleen de metadata van ZFS gecached voor dat filesystem.

Ik raad aan om op het hoofdfilesystem ('tank') de secondarycache op Metadata te zetten. Dan heb je dus metadata cache op L2ARC voor all filesystems. Vervolgens kun je voor specifieke filesystems de cache ook voor data aanzetten, zoals voor tank/vm-images ofzoiets. Of waar anders het nut heeft. Maar zeker niet aanzetten voor alle filesystems.

[killercow]

Duidelijk,

Ik heb de Shingled disks aangeschafd toen er nog geen duidelijke waarschuwingen waren voor de vertragingen, maar Cipher wist dit natuurlijk al vanaf dag een en heeft die omdat hij omnipresent is al aan iedereen gemeld; de storagekoning die hij is, en wij niet zijn. (tjongejonge)

Aan de rest van de mensen in het topic hier die wat minder hoog van de toren blazen:
Ik heb de txg_sync processes nu gereniced naar een wat milder nivo en ben me aan het inlezen wat hier de oorzaak en gevolgen van zijn. Het lijkt er op dat het resync process standaard op -20 draait wat zo ongeveer inhoudt dat alles en iedereen er op moet wachten. Als je dat koppelt aan de potentieel lange write-tijd van de shingled disks zit je zeker met 11 disks blijkbaar continue te wachten tot ze allemaal geflusht zijn. Kleine writes (al is het maar 150KB aan data kunnen die delay al triggeren)

Ik ga wel verder zoeken of het mogelijk is ZFS te vertellen dat hij grotere meer sequentiele chunks moet schrijven naar de disks, op die manier kun je per potentiele hoge wait toch een boel data wegschrijven en blijven een boel 150KB writes mischien ergens op ssd tot er daadwerkelijk genoeg data is en een enkele blib optreedt in plaats van elke 5 seconde een blib in read performance die uiteindelijk elke read buffer aan mn clients starved.

Maargoed, dingen gebruiken waar ze niet voor bedoeld zijn en tweaken tot ze wel werken, dat was ooit gedachte van die hele forum, kennelijk is dat niet meer op zn plaats hier.

[FireDrunk]

Dat vergroten van je transactie groep helpt alleen als je ook een groter write buffer toestaat vanaf de clients.
Sommige applicaties vinden het gewoon niet leuk als hun write 5 seconden delayed wordt.

Het kan zijn dat je teveel synced writes hebt om hier profijt van te hebben.

Dat kan je snel genoeg zien door sync=disabled even aan te zetten, en te kijken of je dan veel beter response tijden hebt.

waarschuwing: Het is niet aan te raden om de optie sync=disabled permanent aan te hebben.

[ Voor 13% gewijzigd door FireDrunk op 22-09-2015 10:49 ]

[Bigs]

Als ik zo de marketingmaterialen van Seagate bekijk over hun Archive harddisks is het inderdaad niet duidelijk dat die niet voor algemeen gebruik bedoeld zijn, maar van de andere kant liggen SMR harddisks ook niet bij de computerwinkel op de hoek in de winkel dus je komt er ook niet zomaar aan.

CoW filesystems als ZFS lenen op zich prima voor SMR schijven (mits je I/O patroon daar ook bij past) dus er zal op termijn wel een patch voor ZFS komen die het filesystem SMR zone aware maakt, als er voldoende vraag naar is.

[FireDrunk]

Heel simpel: De schijven zijn getarget op 180TB per jaar. Dat is dus ~500GB per dag.

~5.9MB/s continu gemiddeld.

[MikeVM]

Verwijderd schreef op dinsdag 22 september 2015 @ 07:36:
[...]

Plex zit nu op versie 0.9.12.11.1406 en die versie zit ook in ZFSguru build 004. Lijkt mij aardig up-to-date?

code:

Powered by ZFSguru version 0.2.0-rc
  Running official system image 10.1-002 featuring FreeBSD 10.1-RC1 with ZFS v5000.

ik heb hier een halfjaar geleden plex via de webui geinstalleerd, deze zit op Version 0.9.9.13, de updateknop binnen plex werkt niet.

als ik een nieuwere zfsguru installeer 10.1-001/11.0-001/11.0-002, en plex via de webui installleer krijg ik een nog oudere versie.

moet ik plex dan installeren via ssh?

[Verwijderd]

Je draait de oude versie van ZFSguru: 0.2. De nieuwe versie is 0.3 - deze is echter niet compatible met de oude. Dus die moet je opnieuw installeren. Die kun je downloaden op de website van ZFSguru, in LiveCD of USB-stick formaat.

[MikeVM]

oh, jammer dat dat niet aangegeven wordt op mn server dat er nog een nieuwe versie beschikbaar is.


is dat een volledig nieuwe installatie dan?

[ Voor 53% gewijzigd door MikeVM op 22-09-2015 17:28 ]

[Verwijderd]

Pas als 0.3 of 0.4 voldoende mature is, over enkele maanden, zal 0.2 final komen met een grote banner dat je moet upgraden. Voor nu is het jouw keuze om te upgraden of niet. De oude werkt prima, maar heeft oudere versies van addons. Wil je nieuw spul dan zul je met de nieuwe versie moeten werken.

Wil je 0.3 draaien dan kun je de USB-stick of LiveCD downloaden, daarmee je systeem booten, je pool importeren en 0.3 installeren. Je data blijft behouden, je instellingen worden gereset. Vanaf 0.4 kun je je instellingen migreren naar nieuwe installaties, maar dat gaat niet met 0.2 werken. 0.2 = End of Life.

[MikeVM]

ok, duidelijk, thx!

kan ik mijn plex database overzetten?
ill probably need to google that..

[Verwijderd]

Ik weet even niet waar dat wordt opgeslagen. Kan zijn op je oude installatie, die wordt niet overschreven als je een nieuwe installatie doet! Maar overzetten is wel handmatig wat werk. Kan ik je wel bij helpen via DM.

Als de data in de service filesystem wordt opgeslgen, dus <poolnaam>/zfsguru/services/<installatienaam> zoals tank/zfsguru/services/10.1-001, dan is het een heel stuk makkelijker om dat over te zetten.

[pica]

Kort vraagje in verband met hierboven.
Ik draai nu 10.2.002; hier wordt nog met een oudere versie van o.a. Plexpass gewerkt (overigens werkt de status van de service niet goed in het service overzicht, plex zelf werkt wel.), ik zou graag naar 10.2.004 gaan zodat ik de nieuwere versie van de services zou kunnen installeren, echter heb ik echt totaal geen zin en tijd om alles weer opnieuw te moeten instellen.
Worden bij een upgrade binnen de 10.2.x versies de instellingen wel behouden? Dit zou zeker gezien er nu regelmatig nieuwe versies uitkomen wel erg handig zijn.

Bij de 'oude' versies deed ik het upgraden van software via CLI, maar na de upgrade naar de 10.2.002 had ik eigenlijk mijzelf voorgenomen om zoveel mogelijk via de GUI te doen omdat hier te veel tijd in gaat zitten.

[ Voor 7% gewijzigd door pica op 23-09-2015 14:14 ]

[FireDrunk]

Nope, dat is een "Migration Manager" feature die nog gepland staat voor... ' ooit '...

[CurlyMo]

Een simpele maar doeltreffende manier is al je (bestanden met) instellingen op een aparte ZFS zetten. Vervolgens maak je daarbij een scriptje die al die bestanden symlinked naar hun standaard locatie. Bijv.

code:

# ls -Al /usr/local/etc/smb.conf
lrwxr-xr-x  1 root  wheel  29 Aug 15  2014 /usr/local/etc/smb.conf -> /settings/samba/smb.conf

Na een herinstallatie kan je makkelijk al je instellingen weer terugzetten door het draaien van je ene script. Aangezien je pools vrij snel in het boot proces worden geïmporteerd loop je ook geen risico dat je programma starten voordat je instellingen zichtbaar zijn.

[FireDrunk]

Damn, wel een goed idee, maar volgens mij zijn dat hier (bij mij) best veel scriptjes dan...
Maar goed, als je het goed doet, hoef je het ook maar weinig te onderhouden...

Tis een investering denk ik dan.

[Verwijderd]

@pica: kijk even waar Plex zijn data opslaat. Is dat in de services directory? Zo ja is het een eenvoudige klus met een enkele kopieeractie.

@CurlyMo: dus dan ga je symlinken, maar heb je na elke upgrade alsnog een script nodig? Dan kun je het net zo goed alleen met een script doen. Voor de upgrade alles kopiëren naar een plek op je pool en na de upgrade weer terugzetten. Dat is wat ik doe.

[ Voor 5% gewijzigd door Verwijderd op 23-09-2015 16:27 ]

[FireDrunk]

Als je symlinked hoef je het niet te kopieren voor je gaat upgraden.
En als je het los zet, kan je makkelijk dat losse filesystem backuppen dmv send & receive.

Goed idee hoor CurlyMo!

[Verwijderd]

Maar je moet nog wel de symlinks weer herstellen na elke upgrade, dus een script moet je sowieso draaien. Maakt dus niet zo heel veel verschil denk ik. Wat ik doe betekent ook dat je de configuratiebestanden allemaal als een backup apart hebt.

Ik hoef na een upgrade enkel een copy-actie te geven: cp -Rp <backup> / want de backup-map is vanaf de root relatief, dus <backup>/usr/local/etc/smb.conf bijvoorbeeld. Dan heb je ook maar één copy-actie nodig. Het script heb je enkel nodig als je de configuratiebestanden wilt bijwerken.

[FireDrunk]

Zit ook weer wat in. Dan ben je ook beschermt tegen user-error... Dat is ook wel weer handig

[Verwijderd]

Nou ik snapshot wel elke keer. Beter te veel snapshotten dan te weinig.

[FireDrunk]

Blijf het onhandig vinden dat ze daar niet makkelijk losse tools voor hebben...

ipv dat ze nou zfs list -t snapshot omzetten naar zfs snapshot list

[CurlyMo]

Het nadeel van de kopieer manier is wanneer je aanpassingen doet je zowel je kopie als je bron bij moet werken. Ook bij een upgrade van het pakket kan het niet automatisch je configuratie aanpassen. Je moet dus zelf gaan zitten uitpluizen wat er is veranderd en dit synchroniseren.

[Verwijderd]

Voordeel is weer dat je de oude configuratie behoud. Dus bij een upgrade pas je verder niets aan de huidige configuratie, en ook de configuratie van nog oudere installaties blijft gewoon behouden. Zou je dan terug willen, is alles intact op het moment zoals je het hebt achtergelaten.

Maar alles heeft zijn voors en tegens. Er zijn meerdere wegen naar Rome.

@FireDrunk: is inderdaad wel irritant; eerst liet zfs list ook snapshots zien, nu is dat verhuist naar list -t snapshot; hoe jij het zegt zou wel fijn zijn, of gewoon shorthand 'zfs snapshot' voor alle snapshots en 'zfs snapshot tank' voor het displayen van alle snapshots op filesystem tank. En je moet dan @ gebruiken om daadwerkelijk een snapshot aan te maken, anders krijg je ze alleen te zien.

[pica]

Bedankt voor de antwoorden, echter als ik dit zo lees dan denk ik dat ik beter weer met de CLI aan de slag kan gaan.

[Verwijderd]

Wat je simpelweg eens kunt proberen is een pkg upgrade plexmediaserver-plexpass dat is voorlopig denk ik het makkelijkste voor je als het puur om Plex te doen is.