Het grote ZFS topic

[riwi]

Da's mooi. Bedankt. Ik zie ook haakse kabels met de hoek "naar boven".
In de Lian Li 4-in-3 heb je haakse kabels nodig maar de meegeleverde 4 kabels hoeken de verkeerde kant op zodat de kabels niet door de kabelgoot gaan maar uitkomen aan de zijde waar geen plek is voor kabels.

[Verwijderd]

riwi schreef op dinsdag 25 augustus 2015 @ 10:49:
Wat is de reden dat men hier aanraad om te importeren met "/dev/disk/by-partlabel/" ipv met "/dev/disk/by-id".
Ik vind de tweede veel prettiger. Dan kan ik direct zien welke disk er vervangen moet worden als ZFS over een schijf klaagt door op het stickertje op de harddisk het serienummer te vergelijken met de printout van zpool status.

Dus jij vindt 937849823742398749283794273 makkelijker dan 'Samsung-disk4' ? Ik snap dat niet....

Ik denk juist dat de kans dat je fouten gaat maken, enorm veel hoger is als je met IDs werkt. Met een zelfgekozen naam bepaal je zelf helemaal wat je wilt. Je kunt beginnen met het serienummer van de disk, of zelf iets kiezen. Je kunt de naam ook een indicatie laten zijn van de fysieke plek in de behuizing.

Is een zelfgekozen naam niet ALTIJD beter dan een random ID?

Ik heb mijn 2de NAS PC nu goed draaiend met ZoL. Ik had wat hardware problemen met een kortgesloten pin in de socket. Dat is nu recht gezet en nu draait de machine perfect met 32GB ECC geheugen. Supermicro X10-SL7F met 1 SSD voor boot en 13x 4TB Seagate in een RAIDZ2 pool (44TB netto).

Plaatjes : http://etmriwi.home.xs4all.nl/pc/pc_fileserver.htm

Je hebt een mooie kast enzo. Maar ik vind wel dat je je disks erin weggepropt hebt. Je hebt nu voor alle disks actieve koeling nodig omdat ze totaal geen natuurlijke warmtedissipatie krijgen. Ik ben hier zelf geen voorstander van.

Maar, voordeel is wel dat je kast weinig ruimte inneemt voor zoveel disks. En met kortere SATA kabels kun je de pijn nog ietwat verzachten. Je hebt ze al vanaf 10 centimeter overigens. Als je ze echt niet kunt vinden, kan ik je wellicht helpen.

[CurlyMo]

Wat CiPHER zegt inderdaad.

Je kan natuurlijk je serienummer terug laten komen in je labels. Dat doe ik zelf ook zo:

code:

.       NAME          STATE     READ WRITE CKSUM
        data          ONLINE       0     0     0
          raidz2-0    ONLINE       0     0     0
            gpt/7L60  ONLINE       0     0     0
            gpt/7JT9  ONLINE       0     0     0
            gpt/8NY3  ONLINE       0     0     0
            gpt/0T7E  ONLINE       0     0     0

Dit zijn gewoon de laatste 4 tekens van elk serienummer. Toen ik nog verschillende schijven door elkaar had, zette ik er nog SG (seagate), SS (Samsung) en WD (Western-Digital) voor. Daarbij heb ik stickers op de tray met dezelfde code zodat je de schijf er niet eerst uit hoeft te halen om te zien welk serienummer waarbij hoort.

[dcm360]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 11:19:
[...]

Dus jij vindt 937849823742398749283794273 makkelijker dan 'Samsung-disk4' ? Ik snap dat niet....

Ik denk juist dat de kans dat je fouten gaat maken, enorm veel hoger is als je met IDs werkt. Met een zelfgekozen naam bepaal je zelf helemaal wat je wilt. Je kunt beginnen met het serienummer van de disk, of zelf iets kiezen. Je kunt de naam ook een indicatie laten zijn van de fysieke plek in de behuizing.

Is een zelfgekozen naam niet ALTIJD beter dan een random ID?

Ik ben het hier eens met riwi. Ik heb naast de bays in de behuizing labels hangen met het serienummer van de schijf er op, dus als er iets is met de schijf scsi-1ATA_TOSHIBA_DT01ABA300_Z34EN32GS weet ik prima dat het de schijf is met Z34EN32GS op de sticker er naast. Op de sticker heb ik ook nog de naam van de zaak staan waar de schijf vandaan komt, de aanschafdatum en het ordernummer. Lekker makkelijk

[Verwijderd]

TOSHIBA staat vaak niet in het serienummer. Bovendien zijn serienummers nogal lang. Zoals CurlyMo zegt, vind ik dan veel handiger 'WD_7L60' bijvoorbeeld. Maar al zou je je disk '39284723473297423946278364328' willen noemen, dat kun je altijd nog zelf doen met een zelfgekozen naam.

Kortom, ik herhaal, is een zelfgekozen naam niet ALTIJD beter?

[dcm360]

Ik beweer toch ook niet dat 'TOSHIBA' in het serienummer staat? Het staat echter wel in de link in /dev/disk/by-id/, net als het serienummer daar ook in staat. Ik zie niet in waarom het nuttig is om zelf labels toe te voegen terwijl /dev/disk/by-id/ bij mij voldoet. Je mag zelf prima bepalen dat labels toevoegen handiger is, maar de bewering dat het altijd beter is...?

[Verwijderd]

Altijd beter, omdat een zelfgekozen naam alleen maar voordelen en geen nadelen heeft. Zo kun je de labels veel korter maken, want zo'n lange ID voor elke disk is helemaal niet handig.

Als je een gedeelte van het serienummer in je label wilt hebben, kan dat gewoon, zoals CurlyMo ook doet. Kortom, je kunt bij labels alles, terwijl je bij de 'by-id' ID geen keuze hebt en een lang en niet te onthouden code krijgt. Een zelfgekozen label lijkt mij in alle gevallen beter. Minder kans op user error, kortere label staat veel netter, en je kunt zelf kiezen welk labelschema je het prettigst vindt. Dat is dus geen 'scsi-1ATA_TOSHIBA_DT01ABA300_Z34EN32GS' - waarbij ik bovendien veronderstel dat als je dezelfde disk aan een ATA controller hangt, je label opeens verandert (geen SCSI meer, immers). Kortom, ik denk inderdaad dat het in alle gevallen beter is dat je zelf een label kiest.

[ Voor 4% gewijzigd door Verwijderd op 25-08-2015 12:22 ]

[dcm360]

- Een korte of lange naam maakt geen zak uit. Of ik nu een korte of lange naam tab-complete of op het clipboard zet, het werkt wel.
- Geen keuze hebben kan een voordeel zijn ten opzichte van zelf een onhandige keuze kunnen maken
- Wat betreft user error: ik kan de verkeerde of de goede naam te pakken hebben. Een kort of lang label verandert dat niet...
- Staat netter: het past in mijn console (met ruime marge). Ook heb ik niet de behoefte om tweemaal daags naar een mooi opgemaakt disk-label te kijken, esthetiek boeit me niet dus.
- De kans dat die schijf aan een controller komt waarbij het label niet met scsi begint is zo ongeveer nul - ik heb geen andere soort controllers liggen en de kans dat die er komen is miniem.

Concluderende vraag: Wat is jouw probleem met het feit dat ik vind dat /by-id/ ook kan voldoen?

[FireDrunk]

Op zich is by-id altijd goed, je zit alleen met het minimale risico, dat een disk soms een nieuw id krijgt als hij op een andere controller hangt. Bijvoorbeeld als je een disk verhuist van onboard controller naar een dedicated sas controller is er potentieel de kans dat de disk een nieuw id krijgt in die directory.

Als je je daar bewust van bent, en dat dus gewoon niet doet, kan je prima /by-id gebruiken.

De enige reden waarom ik het doe, is omdat ik eigen labels esthetisch gezien gewoon mooier vind

[Verwijderd]

Geen probleem hoor; mensen moeten doen wat ze zelf willen. Ik denk alleen dat het een verkeerde keuze is. Dat vinden de mensen zelf waarschijnlijk ook, nadat ze hun eerste user-error hebben gemaakt en de verkeerde disk gaan resilveren. User error is zo'n beetje de enige manier om data op ZFS kwijt te raken, en zo heel onschuldig zijn die random IDs ook weer niet.

Iedere computer heeft daarnaast een AHCI controller van je chipset, dus zou je daar je disk op aansluiten dan verandert ook je ID. Dat is niet mijn idee van een 'ID' die hoort uniek te zijn en niet te veranderen. Wat heeft het anders zin als je een ID hebt die verandert; dan hoef je die ook niet op je disk te plakken met een label.

Ik kan geen enkel argument vinden waarom een gegenereerde pseudo-random ID beter zou zijn dan een door de gebruiker gekozen naam. Dat laatste is daarnaast ook een teken dat de gebruiker zelf de disk heeft geformatteerd. Zo kun je dus ook minder fouten maken met een nieuwe vervangende disk, omdat die nog geen GPT label heeft. Dit gebruikt ZFSguru bijvoorbeeld om zeker te weten dat de gebruiker heeft aangegeven dat de disk beschreven mag worden. Een disk met user data erop kan niet worden gebruikt binnen de web-interface, totdat de gebruiker die disk formatteert met een zelfgekozen GPT label. Dat vind ik de juiste manier van doen.

Jouw argument is kort samengevat 'het boeit me niet'. Maar dat kan veranderen zodra je wel een gebruikersfout maakt die wellicht voorkomen had kunnen worden door het gebruik van GPT labels. Ik ben daarvan een groot voorstander. Maar ik respecteer je mening; het is immers ook jouw data.

[dcm360]

Je zegt hetzelfde met andere woorden...

- Welke user error kan ik maken? (en dan met name: wordt dat voorkomen als ik labels gebruik?)
- Met de beste wil van de wereld kan ik deze IDs niet random noemen
- Psst, deze disk zit aan de onboard controller
- ZoL gaat netjes mopperen als je een disk die niet leeg is in een zpool wil stoppen
- Wat ZFSguru doet is irrelevant voor mij, dat ZFSguru precies doet wat jij handig vindt verbaasd me dan weer niet

[ Voor 7% gewijzigd door dcm360 op 25-08-2015 13:22 ]

[riwi]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 12:21:
Altijd beter, omdat een zelfgekozen naam alleen maar voordelen en geen nadelen heeft. Zo kun je de labels veel korter maken, want zo'n lange ID voor elke disk is helemaal niet handig.

Met de dev/disk/by-id hoef je geen extra labels te plakken (doe ik vaak wel overigens).
En je hoeft geen administratie te voeren met serie nummers vs. labelnamen.
De by-id nummers zijn toch niet random? Volgens mij direct gerelateerd aan de disk.

Als je importeert en de disken op andere controllers hebt gehangen dan komt dat automatisch goed. Ook met by-id. Zelfs al zou de disk naam veranderen dan herkent ZoL dat prima en leest de orginele ID uit de metadata. Heb voor deze NAS2 juist 13 ex ZFSguru schijven geimporteerd in ZoL (tweedehands gekocht van jacovn). Enige wat je dan moet doen is een export en een nieuwe import op de /dev/disk/by-id directory.

En ik weet het niet zeker maar bij ZoL wordt aangeraden niet met partities te werken maar hele disks te voeren aan zpool create. En dan kiest ZoL automatische partitie labels volgens mij. En die zijn dan niet mooi en dus niet meer te relateren aan een serienummer.

Maar goed ik snap wel dat slim gekozen partitie label namen best handig kunnen zijn.

vwb mijn NAS PC behuizing was dit een oude behuizing die ik nog had. Omdat de x10sl7f 14 sata's heeft heb ik 13 schijven in de behuizing gepropt zodat ik effectief zo veel mogelijk ruimte overhoud na de ZFS raidz2 indeling. Mijn NAS PC's staan in een aparte kamer dus ik laat alle fans vol blazen zodat de disks koel blijven. NAS1 heeft in de LianLi D8000 11 fans en deze NAS2 heeft er nu 4. Ik denk dat NAS2 op termijn ook naar een D8000 kast gaat als er nog 12 of 13 disks bij komen later. Dan zal ook de voeding vervangen moeten worden.

[begintmeta]

Je kan altijd nog zelf automatisch gegenereerde ids customizen door wat te klooien met udev

[Verwijderd]

riwi schreef op dinsdag 25 augustus 2015 @ 13:23:
Met de dev/disk/by-id hoef je geen extra labels te plakken (doe ik vaak wel overigens).
En je hoeft geen administratie te voeren met serie nummers vs. labelnamen.
De by-id nummers zijn toch niet random? Volgens mij direct gerelateerd aan de disk.

Als je ze aan een andere controller hangt, kan de ID veranderen. Dus hoe je dat wilt noemen prima, maar ik noem het dan 'random'. Het is geen persistent label die je disk krijgt, zoals wel het geval is als je GPT labels gebruikt. Hoe je je disk ook aansluit, op welk OS, je partitie heeft een door jou gekozen naam.

Administratie voeren hoeft natuurlijk niet, want je kunt de door jou gekozen labelnaam zo indelen zoals je wilt. Werk je graag met serienummers, dan kun je iets maken als 'Samsung-disk02-Q4LPT' waarbij de laatste vijf letters een deel van het serienummer zijn, zoals CurlyMo bijvoorbeeld doet. Zelf vind ik het handiger om met disk nummers te werken. Disk nummer 6 koppel ik dan aan een getal wat ik met permanent marker op de achterkant van de disk schrijf. Dus '6' op de disk komt overeen met 'Green-4TB-disk06' bij mij. Dan weet ik zeker om welke disk het gaat. Dat labelen moet je dan wel in het begin doen. Maar lijkt mij handiger dan serienummer, want dat kan ik alleen zien als ik de disk uit de 3,5" bay haal. Ik zie liever direct: 'oh disk6 dat moet deze fysieke disk zijn'.

Als je importeert en de disken op andere controllers hebt gehangen dan komt dat automatisch goed. Ook met by-id. Zelfs al zou de disk naam veranderen dan herkent ZoL dat prima en leest de orginele ID uit de metadata.

Bij ZoL werkt dat alleen als je importeert. Alleen BSD doet het op de juiste manier, met device tasting. Bij elke boot wordt elke schijf - elke GEOM device zelfs - geproeft en aan een ZFS pool toegewezen. Bij ZoL krijg je iets als 'corrupted metadata' te zien als de volgorde van je disks is veranderd zonder dat je opnieuw hebt geïmporteerd. Dit kan voor een beginnende gebruiker een schrikreactie teweegbrengen, en die denkt misschien wel dat het over en uit is met zijn data. Dat het wel aan de gebruiker te wijten zou zijn dat hij of zij iets fout heeft gedaan.

Heb voor deze NAS2 juist 13 ex ZFSguru schijven geimporteerd in ZoL (tweedehands gekocht van jacovn). Enige wat je dan moet doen is een export en een nieuwe import op de /dev/disk/by-id directory.

Dat is dus jammer, want dan behoud je niet de GPT labels. Dat kan wel als je importeert op /dev/disk/by-partlabel/.

En ik weet het niet zeker maar bij ZoL wordt aangeraden niet met partities te werken maar hele disks te voeren aan zpool create.

iiiieeeuwww! Dat is al helemaal smerig!

Denk aan een beginnende gebruiker die zijn ZFS disks eventjes aan Windows koppelt. Windows vraagt doodleuk "wilt u deze schijf initialiseren?" en zo'n doodonschuldige vraag beantwoordt de gebruiker dan met ja. TADA! Zeg maar dag tegen je ZFS schijf - want hij is dan opnieuw geformatteerd en dat betekent dat ZFS je schijf ook niet meer zal herkennen. Ha! Goed genaaid ben je dan....

Natuurlijk gebruik je altijd partities, om een heleboel redenen:

• Disks vervangen die net iets kleiner zijn - niet meer mogelijk als je geen partities gebruikt. Je dwingt daarmee ook af dat alle vervangende disks ook geen partities mogen hebben. Zo ontzettend dom.
• Je hebt geen mogelijkheden meer voor GEOM containers, zoals full disk encryptie wat je achteraf prima kunt doen, mits je partities gebruikt. Dan heb je namelijk altijd nog een sector (512 bytes) aan het einde over om de GELI encryptie metadata te schrijven. Geen idee hoe dit onder Linux werkt overigens, maar mogelijk hetzelfde principe of je moet de metadata elders schrijven ipv on-disk wat natuurlijk stom is want je wilt juist on-disk metadata hebben.
• Je kunt sommige controllers niet meer gebruiken, zoals sommige Silicon Image fakeRAID controllers. Als je de laatste sector beschrijft, kan het zijn dat de RAID-firmware die tijdens het booten kijkt naar de laatste sector op elke schijf, een error geeft. Je moet dus de laatste sector vrijhouden bij dit type controllers.
• Je wilt niet dat Windows of een ander dom OS zomaar je disken gaat formatteren omdat het denkt dat deze ongeformatteerd zijn. Nog erger is dat Windows de vraag op een heel domme/nerdachtige manier stelt, waardoor de gebruiker helemaal niet doorheeft dat de disks geformatteerd worden en data op de disks wordt vernietigd.
• Zonder GPT partities ook geen GPT label, en dat werkt user-error weer in de hand met disk IDs die ook nog eens kunnen veranderen.

De enige reden om volledige disks te gebruiken is wanneer je Solaris gebruikt - die dankzij ouderwetse UFS technologie standaard de write buffercache van je hardeschijf uitschakelt als je partities gebruikt. Dit omdat het ouderwetse UFS filesystem niet tegen verloren writes kan. Vergelijkbaar met het Windows 95-tijdperk waarbij tijdens het booten je altijd Scandisk moest draaien om FAT filesystemschade te repareren. Dit kwam doordat FAT geen voorziening heeft om verloren writes door de DRAM-buffercache van hardeschijven op te vangen. NTFS, Ext3/4 en HFS en UFS2+SU hebben dit allemaal wel. Solaris heeft dit niet. Dus wat doen ze? Doodleuk je write buffercache uitschakelen, zodat je disks nog maar tegen 1MB/s schrijven. Jeeeeej!

En dan kiest ZoL automatische partitie labels volgens mij.

Je disks krijgen automatisch een ID, maar dit is geen partitielabel. Die kiest de gebruiker zelf.

Maar goed ik snap wel dat slim gekozen partitie label namen best handig kunnen zijn.

Fijn dat in elk geval iemand er enig voordeel in ziet.

Mijn NAS PC's staan in een aparte kamer dus ik laat alle fans vol blazen zodat de disks koel blijven.

Als het toch in een aparte kamer staat, waarom dan zo'n mooie en dure kast? Als het in het zicht staat en je de afmetingen beperkt wilt houden, kan ik je keuze begrijpen. Maar als die twee factoren niet of minder van belang zijn, had ik een andere behuizing logischer gevonden. Een 4U behuizing bijvoorbeeld, of juist iets met zelfbouw zoals ik doe, zodat je geen actieve koeling meer nodig hebt voor de schijven. Gewoon zelf een metalen rack maken met schroefgaatjes en daar de disks aan bevestigen. Met genoeg metaal heb je een grote heatsink aan je schijven hangen die de warmtedissipatie voor je regelt, zonder ook maar één fan. Scheelt lawaai, stof en is daarnaast ook zuiniger.

[CurlyMo]

Het probleem van disk labels zoals "DISK6" is het moeten vervangen van een schijf. Disk 6 is aan het falen, je hangt er een nieuwe bij, die na het vervangen DISK6 wordt, maar aangezien DISK6 al een gebruikte label is, noem je hem DISK7. Na het replacen moet je hem hernoemen naar DISK6.

[dcm360]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 14:30:
[...]

iiiieeeuwww! Dat is al helemaal smerig!

Het is alleen smerig als je op basis daarvan verkeerde aannames over de werking van ZoL gaat maken - zoals je nu aan het doen bent helaas. Het verhaal onder deze regel is gewoon nonsens, omdat ZoL de schijf initialiseert en partities aanmaakt.

[Verwijderd]

CurlyMo schreef op dinsdag 25 augustus 2015 @ 14:48:
Het probleem van disk labels zoals "DISK6" is het moeten vervangen van een schijf. Disk 6 is aan het falen, je hangt er een nieuwe bij, die na het vervangen DISK6 wordt, maar aangezien DISK6 al een gebruikte label is, noem je hem DISK7. Na het replacen moet je hem hernoemen naar DISK6.

Dan noem je het toch geen Disk7 maar Disk6b bijvoorbeeld? Weet je ook weer dat dit de disk is die je ooit hebt vervangen, omdat alleen die disk een 'b' suffix heeft. Ik vind dat wel handig.

dcm360 schreef op dinsdag 25 augustus 2015 @ 14:53:
Het is alleen smerig als je op basis daarvan verkeerde aannames over de werking van ZoL gaat maken - zoals je nu aan het doen bent helaas. Het verhaal onder deze regel is gewoon nonsens, omdat ZoL de schijf initialiseert en partities aanmaakt.

Oke, daarin heb je een punt. Als ZoL er zelf partities op pleurt, is een deel van mijn argumenten niet meer geldig. Maar toch is dit vreemd; wat als de gebruiker inderdaad een whole-disk wilt gebruiken en geen partities? Je zegt A, maar je krijgt B. Ik dacht altijd dat de gebruiker de baas was.

[riwi]

Inderdaad maakt ZoL zelf de GPT partities aan. 2 of 3 stuks dacht ik. Inderdaad ter bescherming van vervangen met een disk die een paar bytes kleiner is en voor die controllers die stiekem op de disk schrijven.

Kwa kast. Ik ben niet zo'n doe het zelfer met metaal en dergelijke. En de Lian Li kast had ik er 3 van staan. Dus hergebruik is ook wel fijn.

En de duurdere Lian Li kasten zijn omdat dan alles goed werkt en past doorgaans. Eenmaal een coolermaster van 50 euro gehad en daar brak ik binnen een uur DHZ werk allerlei dingen van af.

[ Voor 21% gewijzigd door riwi op 25-08-2015 15:06 ]

[Verwijderd]

Het is zeker een mooie kast en als je 10cm - 20cm SATA kabels zou gebruiken zou het intern nog wat netter zijn en de airflow ten goede komen. Als je deze graag wilt hebben, maar niet kunt vinden online, kan ik misschien nog wat voor je betekenen.

[dcm360]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 14:59:
[...]
Oke, daarin heb je een punt. Als ZoL er zelf partities op pleurt, is een deel van mijn argumenten niet meer geldig. Maar toch is dit vreemd; wat als de gebruiker inderdaad een whole-disk wilt gebruiken en geen partities? Je zegt A, maar je krijgt B. Ik dacht altijd dat de gebruiker de baas was.

Tja, het heeft zo zijn voors en tegens, maar ik ben het wel met jou eens dat het een wat onhandige keuze is om geen partities te gebruiken. Ook in dit geval neig ik een beetje naar beter geen keuze dan het kunnen maken van een slechte keuze.

Overigens, een stukje over gebruik van /dev/disk/by-id/

[FireDrunk]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 14:30:
[...]

Als je ze aan een andere controller hangt, kan de ID veranderen. Dus hoe je dat wilt noemen prima, maar ik noem het dan 'random'.

Dus omdat iets niet aan jouw eisen voldoet noem je het direct random? Hoezo geef je gebruikers op dit forum dan foutieve informatie... Dat is echt verbastering van de waarheid...

Het is geen persistent label die je disk krijgt, zoals wel het geval is als je GPT labels gebruikt. Hoe je je disk ook aansluit, op welk OS, je partitie heeft een door jou gekozen naam.

Administratie voeren hoeft natuurlijk niet, want je kunt de door jou gekozen labelnaam zo indelen zoals je wilt. Werk je graag met serienummers, dan kun je iets maken als 'Samsung-disk02-Q4LPT' waarbij de laatste vijf letters een deel van het serienummer zijn, zoals CurlyMo bijvoorbeeld doet. Zelf vind ik het handiger om met disk nummers te werken. Disk nummer 6 koppel ik dan aan een getal wat ik met permanent marker op de achterkant van de disk schrijf. Dus '6' op de disk komt overeen met 'Green-4TB-disk06' bij mij. Dan weet ik zeker om welke disk het gaat. Dat labelen moet je dan wel in het begin doen. Maar lijkt mij handiger dan serienummer, want dat kan ik alleen zien als ik de disk uit de 3,5" bay haal. Ik zie liever direct: 'oh disk6 dat moet deze fysieke disk zijn'.


[...]

Bij ZoL werkt dat alleen als je importeert. Alleen BSD doet het op de juiste manier, met device tasting. Bij elke boot wordt elke schijf - elke GEOM device zelfs - geproeft en aan een ZFS pool toegewezen. Bij ZoL krijg je iets als 'corrupted metadata' te zien als de volgorde van je disks is veranderd zonder dat je opnieuw hebt geïmporteerd. Dit kan voor een beginnende gebruiker een schrikreactie teweegbrengen, en die denkt misschien wel dat het over en uit is met zijn data. Dat het wel aan de gebruiker te wijten zou zijn dat hij of zij iets fout heeft gedaan.

Hoe *KOM* je hier bij?? Waar heb je dit vandaan? Ik heb dit echt nog *nooit* gezien bij ZoL... Ik heb me echt nog nooit druk gemaakt over disk volgorde, en heb nog nooit fouten gehad met corrupte metadata. Ook heb ik echt meer dan 10 keer geswitched van onboard controller naar een M1015 en naar een Dell H200 en nog nooit problemen gehad bij het importeren.

Een over dat device tasting, dat doet ZoL echt al heel lang. Onder de SystemD implementaties wordt keurig eerst de zpool.cache ingelezen zoals op elk platform, en daarna wordt er zelfs een auto-import gedaan.

Als je dus een pool in je systeem stopt terwijl deze uit staat, wordt deze keurig geimporteerd (mits je hostid matched, als die niet matched moet je handmatig import -f doen).

[...]

Dat is dus jammer, want dan behoud je niet de GPT labels. Dat kan wel als je importeert op /dev/disk/by-partlabel/.

Waarom *behoud* je de GPT labels niet als je ID's gebruikt? Die kan je gewoon door elkaar gebruiken, maakt geen barst uit. Het zijn niets anders dan symlinks in de /dev tree van Linux. Betekenen verder niks, en hebben geen enkele consequentie.

_{rest van je post heb ik er expres afgeknipt}

[Verwijderd]

FireDrunk schreef op dinsdag 25 augustus 2015 @ 15:34:
Dus omdat iets niet aan jouw eisen voldoet noem je het direct random? Hoezo geef je gebruikers op dit forum dan foutieve informatie... Dat is echt verbastering van de waarheid...

Het is geen persistent label omdat de naam kan veranderen. Dat is mijn punt. Een GPT label blijft hetzelfde tenzij de gebruiker hem aanpast.

Hoe *KOM* je hier bij?? Waar heb je dit vandaan? Ik heb dit echt nog *nooit* gezien bij ZoL...

Nou ik wel. En dit geldt voor alle platforms, in elk geval in het verleden. Ook BSD vroeger, toen er nog geen device tasting werd gebruikt.

Jij zegt dat ZoL ook tasting gebruikt. Dit zou betekenen dat als je de volgorde van de disks omwisselt of de disks op een andere controller gooit, terwijl de zpool.cache onveranderd blijft, je pool gewoon toegankelijk blijft onder de nieuwe devicenamen. Als dit klopt dan is ZoL inmiddels ook aangepast en is Solaris het laatste platform wat nog niet met device tasting werkt. Maar weet je zeker dat het zo werkt?

Ik vermoed namelijk dat de zpool.cache gebruikt wordt om de ZFS pool aan devices te koppelen, zoals in het prille begin onder FreeBSD 7-CURRENT ook werd gebruikt. Een veranderde volgorde betekent dan een ontoegankelijke pool (UNAVAIL) met achter de disks letterlijk '(corrupted metadata)'. Dat houdt in dat ZFS niet de juiste data vindt op de plek waar het dat verwacht. In het verleden is er ook een LBA offset bug geweest die hiervoor heeft gezorgd.

Ik heb me echt nog nooit druk gemaakt over disk volgorde, en heb nog nooit fouten gehad met corrupte metadata. Ook heb ik echt meer dan 10 keer geswitched van onboard controller naar een M1015 en naar een Dell H200 en nog nooit problemen gehad bij het importeren.

Importeren? Dat zei ik niet! Je importeert helemaal niets. Je verandert enkel de disk volgorde. Dan hoort je pool zonder te importeren beschikbaar te zijn. Tenminste, als het klopt wat jij zegt, dat ZoL gewoon de disks proeft en helemaal de zpool.cache niet gebruikt voor het herkennen welke disks bij welke pool hoort.

Een over dat device tasting, dat doet ZoL echt al heel lang. Onder de SystemD implementaties wordt keurig eerst de zpool.cache ingelezen zoals op elk platform, en daarna wordt er zelfs een auto-import gedaan.

Als het klopt wat je zegt, dan heb je gelijk en ik ongelijk. Echter ook in deze quote heb je het over importeren. Dat is uitdrukkelijk niet wat ik bedoel.

Waarom *behoud* je de GPT labels niet als je ID's gebruikt?

De disk zelf behoudt die wel, dat bedoel je denk ik. Maar je snapt mij toch ook wel dat je ZFS pool die niet meer gebruikt?! Dus bij elke volgende import of wat dan ook, gaat hij achter je disk IDs aan en niet je partitielabels. Dat werkt ook zo onder FreeNAS en dat vind ik absoluut niet netjes. De gebruiker heeft niet voor niets zelf een naam gekozen. Dan moet je die ook gebruiken, tenzij de gebruiker aangeeft iets anders te willen met de -d parameter.

[FireDrunk]

Ik zal het eens proberen, volgens mij kan ik het zelfs gewoon hotswappen... een DeviceID is niet afhankelijk van locatie, dus op het moment dat je disks in een andere volgorde weer terugkomen, komt hetzelfde id weer terug, dus kan ZFS gewoon de disk via dezelfde symlink aanspreken.

Vanuit de 'view' van ZFS veranderd er dus niets.

Overigens heb ik ook disks vrolijk omgehangen van controller terwijl ik een pool al geimporteerd had, kan me niet herinneren dat ik daar ooit problemen mee gehad heb.

[Verwijderd]

Ik ben het nu ook aan het proberen met een Ubuntu installatie binnen Virtualbox.

[FireDrunk]

Ubuntu is poep... Pak Fedora of CentOS, dan heb je een echte SystemD implementatie te pakken.

[Verwijderd]

Executing 'grub-install /dev/sda' failed. This is a fatal error.

WTF? Een super-casual installatie van Ubuntu in Virtualbox met lege disks, dat werkt niet?

Dit is dan de makkelijkste en populairste Linux-distributie. Zucht....

Centos ook al gelijk een probleem. Want de website laat me versie '7' downloaden, terwijl 7.1 al in april dit jaar uit zou zijn. Schiet ook niet op zo.

[ Voor 30% gewijzigd door Verwijderd op 25-08-2015 16:41 ]

[FireDrunk]

Grappig, een moderator die een ZFS topic vervuilt met installatieproblemen met Ubuntu onder VirtualBox

Wat voor Disk controller gebruik je?

[Verwijderd]

Gewoon alles standaard gelaten, dus gewoon een SATA (AHCI) controllertype.

Maar laat maar dan. Heb er zo ook weinig zin meer in. En zoals je zegt, het is ook off-topic.

[FireDrunk]

Pak nou Fedora

[riwi]

systemd is toch een vies woord? Bij Slackware geen systemd until hell freezes over.

Volgens mij leest ZoL default de zpool.cache file niet eens, maar pas als het zoeken naar de devices niet lukt. Ik had zelfs ergens gelezen dat ze er helemaal vanaf willen van die cache file.

[Wiebeltje]

Ubuntu 15.04 geeft mij sowieso nog kernel panics na 1.5e dag uptime. Had een reinstall gedaan van mijn NAS maar heb de oude image weer terug gezet. Zodra 0.6.5 uit is zal ik het nog eens proberen. Verder werkte de pool e.d. wel gewoon goed. Automounten tijdens boot met /dev/disk/by-partlabel gaat met systemd ook in een keer goed in tegenstelling tot 14.04.

Edit: deze bug kwam ik tegen: https://github.com/zfsonlinux/zfs/issues/3257

[ Voor 9% gewijzigd door Wiebeltje op 25-08-2015 17:31 ]

[Kortfragje]

FireDrunk schreef op dinsdag 25 augustus 2015 @ 15:34:
[...]

Dus omdat iets niet aan jouw eisen voldoet noem je het direct random? Hoezo geef je gebruikers op dit forum dan foutieve informatie... Dat is echt verbastering van de waarheid...


[...]


_{rest van je post heb ik er expres afgeknipt}

Geef persoonlijk sterk de voorkeur aan "/dev/disk/by-vdev/"


Summary: This approach provides administrative control over device naming using the configuration file /etc/zfs/vdev_id.conf.


eenmalig een file maken met alle labels precies (bijv Slot1_WD_4TB) zoals je wil, geen gedonder met partitioneren (doet zfs voor je), geen gedonder met controllers, alles automagisch..

[Compizfox]

Ik heb zojuist een ZFSGuru-install van 10.1-RC1 naar 10.2-RELEASE geüpdatet. Dit heb ik gewoon gedaan op de manier uit het FreeBSD handbook: eerst een GENERIC kernel bakken en die in /boot/GENERIC plaatsen, en dan het hele freebsd-update-circus volgen.

En ja, ik moest weer shit handmatig mergen.

Maar goed, ik heb eigenlijk een ander probleem. Volgens freebsd-version draai ik 10.2-RELEASE-p1:

# freebsd-version
10.2-RELEASE-p1

Maar, volgens uname -a is de kernel die ik draai nog blijven steken op 10.1-RC1:

# uname -a
FreeBSD hostname 10.1-RC1 FreeBSD 10.1-RC1 #1 r272602: Mon Aug 24 20:23:12 CEST 2015     root@hostname:/usr/obj/usr/src/sys/GENERIC  amd64

Ik ondervindt hier verder geen problemen van, alles lijkt gewoon te werken. Maar betekent dit dat ik inderdaad een oude kernel draai, en zo ja, hoe kan dat? freebsd-update zou toch de GENERIC kernel moeten mee-updaten?

[ Voor 3% gewijzigd door Compizfox op 25-08-2015 18:31 ]

[Verwijderd]

Poeh. Heb je inderdaad wel de kernel geupdate? Zou kunnen dat je nu 10.2 userland draait maar nog met een 10.1-RC1 kernel ofzo. Wel vreemd, want de kernel updaten is wel het makkelijkste wanneer je FreeBSD gaat upgraden.

freebsd-version is inderdaad de userland, uname -a print de kernel. En nog iets:

     -k          Print the version and patch level of the installed kernel.
                 Unlike uname(1), if a new kernel has been installed but the
                 system has not yet rebooted, freebsd-version will print the
                 version and patch level of the new kernel.

Heb je al gereboot?

[Compizfox]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 18:40:
Poeh. Heb je inderdaad wel de kernel geupdate? Zou kunnen dat je nu 10.2 userland draait maar nog met een 10.1-RC1 kernel ofzo. Wel vreemd, want de kernel updaten is wel het makkelijkste wanneer je FreeBSD gaat upgraden.

Ik heb een GENERIC 10.1-RC1 kernel gebakken en die in /boot/GENERIC geplaatst voor het upgraden. Volgens het Handboek zou die automatisch door freebsd-update moeten zijn geüpdatet.

freebsd-version is inderdaad de userland, uname -a print de kernel. En nog iets:

     -k          Print the version and patch level of the installed kernel.
                 Unlike uname(1), if a new kernel has been installed but the
                 system has not yet rebooted, freebsd-version will print the
                 version and patch level of the new kernel.

Heb je al gereboot?

Ik heb zeker al gereboot, 3x zelfs. Heb gewoon het installatieproces gevolgd en je moet op meerdere punten van het upgradeprocess rebooten.

# freebsd-version -k
10.1-RC1

Dus ja, dat is ook de oude kernel. Ik begrijp dat m'n GENERIC kernel dus niet geupdatet is? Wat raar, heb toch het Handboek letterlijk gevolgd.

Ik ga maar handmatig een 10.2-RELEASE kernel bakken dan.

[Verwijderd]

Wat heb je precies gevolgd, freebsd-update of de handmatige make buildkernel/buildworld procedure?

[Compizfox]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 19:49:
Wat heb je precies gevolgd, freebsd-update of de handmatige make buildkernel/buildworld procedure?

freebsd-update, dat was ondertussen wel duidelijk toch?

[Verwijderd]

Mja even voor de zekerheid. Maar dan is het toch wel vreemd. Ik heb zelf niet veel ervaring met freebsd-update. Slechts twee keer gebruikt. Ik vind het fijner om het handmatig te doen dan snap ik tenminste wat er gebeurt.

Voordeel is wel dat je gewoon buildkernel/installkernel kunt gebruiken - je hoeft geen mergemaster meer te doen als je userland al in orde is. Dus dat is vrij makkelijk dan:

cd /usr/src
svn co svn://svn.freebsd.org/base/releng/10.2
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot

[Compizfox]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 19:56:
Voordeel is wel dat je gewoon buildkernel/installkernel kunt gebruiken - je hoeft geen mergemaster meer te doen als je userland al in orde is. Dus dat is vrij makkelijk dan:

cd /usr/src
svn co svn://svn.freebsd.org/base/releng/10.2
make buildkernel KERNCONF=GENERIC
make installkernel KERNCONF=GENERIC
reboot

Ja, dat was ik al van plan. Is er eigenlijk nog een verschil tussen bovenstaande methode, die ook wordt beschreven in het hoofdstuk Building and Installing a Custom Kernel van het Handboek, en de methode die aangeraden wordt door het Handboek voor het compilen van een GENERIC kernel voor freebsd-update?

# cd /usr/src
# make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null

[ Voor 11% gewijzigd door Compizfox op 25-08-2015 20:05 ]

[Verwijderd]

Ik gebruik die parameters niet, maar ik neem aan dat dit je /etc/make.conf en /etc/src.conf overruled.

Als je van ZFSguru afkomt, zal dit inderdaad wel uitmaken. Met name /etc/src.conf zorgt dat OFED infiniband wordt ingeschakeld. Ik denk dat /etc/make.conf bij ZFSguru leeg is.

Je kunt ook handmatig even de OFED in /etc/src.conf uitschakelen door een # comment karakter toe te voegen.

make kernel is een make buildkernel en make installkernel in één. Ik doe dat zelf liever apart. Maar kan allemaal prima.

[Compizfox]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 20:17:
Ik gebruik die parameters niet, maar ik neem aan dat dit je /etc/make.conf en /etc/src.conf overruled.

Als je van ZFSguru afkomt, zal dit inderdaad wel uitmaken. Met name /etc/src.conf zorgt dat OFED infiniband wordt ingeschakeld. Ik denk dat /etc/make.conf bij ZFSguru leeg is.

Je kunt ook handmatig even de OFED in /etc/src.conf uitschakelen door een # comment karakter toe te voegen.

make kernel is een make buildkernel en make installkernel in één. Ik doe dat zelf liever apart. Maar kan allemaal prima.

/etc/src.conf bestaat bij mij niet. In /etc/make.conf zijn de enige uncommented regels:

code:

WITH_PKGNG=yes
WITHOUT_X11=yes

Wat is dan precies het verschil tussen KERNCONF=GENERIC en __MAKE_CONF=/dev/null SRCCONF=/dev/null? Zouden die niet hetzelfde resultaat moeten opleveren, aangezien de laatste methode (__MAKE_CONF en SRCCONF) aangeraden wordt in het freebsd-update-artikel voor het bouwen van een GENERIC kernel?

[Verwijderd]

__MAKE_CONF=/dev/null SRCCONF=/dev/null zorgt er gewoon voor dat wat er in /etc/make.conf en /etc/src.conf staat, niet wordt gebruikt. Althans, dat lijkt mij zeer aannemelijk. In jouw geval zou het niet mogen uitmaken, omdat je geen /etc/src.conf hebt (die bestaat wel bij ZFSguru overigens!) en in je /etc/make.conf staat verder niets spannends. PKGNG is tegenwoordig allang standaard en WITHOUT_X11 heeft alleen betrekking op ports, niet op de base (userland/kernel).

[Compizfox]

Verwijderd schreef op dinsdag 25 augustus 2015 @ 20:39:
__MAKE_CONF=/dev/null SRCCONF=/dev/null zorgt er gewoon voor dat wat er in /etc/make.conf en /etc/src.conf staat, niet wordt gebruikt. Althans, dat lijkt mij zeer aannemelijk. In jouw geval zou het niet mogen uitmaken, omdat je geen /etc/src.conf hebt (die bestaat wel bij ZFSguru overigens!) en in je /etc/make.conf staat verder niets spannends. PKGNG is tegenwoordig allang standaard en WITHOUT_X11 heeft alleen betrekking op ports, niet op de base (userland/kernel).

Dat klinkt logisch.

Betekent dat dan dat de default waarde voor KERNCONF, GENERIC is? Aangezien ik geen KERNCONF-argument mee hoef te geven om een GENERIC-kernel te builden.

[Verwijderd]

Dat klopt.

Heel vaak zeggen mensen ook: je hoeft geen KERNCONF=GENERIC op te geven als het de GENERIC-kernel betreft. Ik doe het altijd wel, omdat je dan gelijk weet welk commando je nodig hebt als je zelf een kernel wilt bakken. Een parameter teveel bestaat niet, te weinig wel.

[staticint]

Dag allemaal,

Ik wil graag even inhaken/voortborduren op de gpt-labels vs diskid discussie. Pas geleden ben ik overgestapt van Debian Wheezy i.c.m. ZoL 0.6.4 naar FreeBSD 10.1 (ondertussen 10.2). De zpool is toentertijd aangemaakt door volledige disks door te geven aan ZoL. Het exporteren/importeren van Debian naar FreeBSD ging zonder problemen, maar mijn disklabels zien er als volgt uit:

code:

NAME                                              STATE     READ WRITE CKSUM
zstorage                                          ONLINE       0     0     0
  raidz2-0                                        ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYVp1  ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WCC4N76L0NJ1p1  ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WCC4N76L0T3Tp1  ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WCC4NKNTZ35Rp1  ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WCC4NKNTZPDDp1  ONLINE       0     0     0
    diskid/DISK-%20%20%20%20%20WD-WMC4N0D566A3p1  ONLINE       0     0     0

Wat me opvalt zijn de meerdere opeenvolgende '%20's in de diskid. Ik vraag mij af of dit misschien problemen op gaat leveren in de toekomst? Is het verstandig dit om te zetten naar gpt-labels? (hoe dat moet zal vast wel te googlen zijn) Of is het beter dat ik er vanaf blijf?

Als ik trouwens een gpart show uitvoer krijg ik dit te zien:

code:

=>        34  5860533101  diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYV  GPT  (2.7T)
          34        2014                                              - free -  (1.0M)
        2048  5860513792                                           1  !6a898cc3-1dd2-11b2-99a6-080020736631  (2.7T)
  5860515840       16384                                           9  !6a945a3b-1dd2-11b2-99a6-080020736631  (8.0M)
  5860532224         911                                              - free -  (456K)

Dit ziet er heel anders uit dan mijn ZFS-on-root disks. Wat is die 8M grote partitie bijvoorbeeld? En vanwaar de GUID's i.pv. een nette aanduiding zoals hieronder?

code:

=>       34  976773101  ada0  GPT  (466G)
         34          6        - free -  (3.0K)
         40       1024     1  freebsd-boot  (512K)
       1064   67108864     2  freebsd-swap  (32G)
   67109928  909663200     3  freebsd-zfs  (434G)
  976773128          7        - free -  (3.5K)

In ieder geval... Alles werkt naar behoren hoor. Ik ben niet van plan er mee te gaan pielen als het niet nodig blijkt te zijn, maar vroeg me deze dingen gewoon af.

offtopic:
p.s. FreeBSD werkt wel erg lekker. Heb 2 debian vm's met bhyve op een zvol draaien

[riwi]

Die 8MB grote partitie is aangemaakt door ZoL om je te beschermen tegen slechte sata kaartjes die op de laatste sector schrijven en om ervoor te zorgen dat als je deze disk wil vervangen door een van een ander merk die misschien een paar kbytes kleiner is dat het dan toch werkt.

De %20 zijn ascii spaties op een of andere manier zijn die ervoor gekomen in BSD. Dat is wel raar. of het problemen zal geven weet ik niet. Maar je kan misschien beter een export / import doen met de ID's die je het liefst zou zien. En dan misschien wel die mooie GPT label namen die Cipher graag ziet. Alhoewel ik niet zeker weet of je die GPT labels zomaar mag wijzigen.

[revox862]

disk_ident wordt in dit geval gebruikt, niet het GPT label.
kern.geom.label.disk_ident.enable="0" in /boot/loader.conf zetten/toevoegen en rebooten zou het moeten "oplossen".

[ Voor 8% gewijzigd door revox862 op 26-08-2015 20:58 ]

[Verwijderd]

staticint schreef op woensdag 26 augustus 2015 @ 14:55:
Ik wil graag even inhaken/voortborduren op de gpt-labels vs diskid discussie.

Yes! Nog meer kolen op het vuur!

Pas geleden ben ik overgestapt van Debian Wheezy i.c.m. ZoL 0.6.4 naar FreeBSD 10.1 (ondertussen 10.2).

De zpool is toentertijd aangemaakt door volledige disks door te geven aan ZoL.

Het exporteren/importeren van Debian naar FreeBSD ging zonder problemen, maar mijn disklabels zien er als volgt uit: *knip*

Wat me opvalt zijn de meerdere opeenvolgende '%20's in de diskid. Ik vraag mij af of dit misschien problemen op gaat leveren in de toekomst?

%20 is een spatie. De diskid is gewoon een soort symbolic link naar de gehele disk, dus geen partities ofzoiets maar de volle hele disk vanaf LBA0.

Het is niet supernetjes, maar ik zie er geen problemen mee. De %20 zie je omdat de DISKID de description van je schijven pakt en daar zitten spaties in. BSD zou dit allemaal prima moeten slikken en bovendien als je van platform wisselt ziet dat nieuwe platform (Linux of Solaris) gewoon weer hele disks, dus dat diskid wordt nergens opgeslagen op de disks zelf.

Is het verstandig dit om te zetten naar gpt-labels? (hoe dat moet zal vast wel te googlen zijn) Of is het beter dat ik er vanaf blijf?

Daar is het nu te laat voor, om meerdere redenen:

• Je kunt niet zomaar een partitie maken op een schijf die in gebruik is. Je zult je schijf eerst moeten detachen/offline-en voordat je ernaar mag schrijven. Al is daar een trucje voor (debugflags=0x10).
• Als je de disk offline haalt en er partities op zet, geldt het als lege schijf. ZFS zal de partitie niet als een ZFS disk herkennen. Dus je moet vanaf 0 resilveren. Door de shift in LBA offset (alles staat een stukje verderop) zal ook elke data opnieuw worden beschreven. Dus een lange rebuild wordt het.
• Omdat je hele disks gebruikt, is elke sector van je hardeschijf in gebruik. Dat is het grootste probleem, want als je bovenstaande allemaal zou doen en je wilt de 'nieuwe' schijf met GPT partities aan je ZFS pool geven, dan klaagt hij dat je nieuwe disk met GPT partitie kleiner is dan de hele disk die ZFS gewend was. En dan gaat het hele feest niet door; één sector te klein en ZFS weigert doodleuk je schijf.

Edit: dat laatste punt is dus mogelijk niet helemaal waar...

Het zou dus alleen werken als je je hele pool overnieuw maakt. Dus backuppen en dan echt opnieuw aanmaken.

De voordelen van GPT partities zijn besproken. Maar als je eenmaal in deze situatie zit, moet je wat kritischer gaan kijken of je er ook echt wat mee opschiet. Ik zelf vind het risico van dataverlies het grootst. Dat risico bestaat als je de schijven ooit aan Windows zou aankoppelen. Die vraagt dan heel onschuldig met een popup of je de schijf/schijven wilt 'initialiseren'. Dat klinkt zo onschuldig dat veel mensen op Next/Volgende klikken en dan is je data dus pleite omdat 'initialiseren' in Windows-jargon betekent dat de schijf wordt geformatteerd met een nieuw partitieschema. Daarbij wordt de eerst X MB overschreven met nullen en dat is funest.

Kortom, als je dit risico kent en je zorgt dat Microsoft nooit met zijn tengels aan je schijven zit, dan zijn de voordelen van GPT vrij marginaal. Zeker wanneer je dit afzet tegen de moeite die je moet doen om dit allemaal te veranderen.

Als ik trouwens een gpart show uitvoer krijg ik dit te zien:

Oke dat is dus voor mij nieuw. Ik ken geen situatie dat de diskid wordt gebruikt, maar dat deze naar LBA34 wijst. Je hebt dus kennelijk wel GPT partities maar die worden niet gebruikt. Aangezien ZFS de diskid pakt en deze op LBA34 zou beginnen, betekent dit waarschijnlijk dat je GPT partities die op LBA2048 beginnen (1024K offset) niet worden gebruikt. Dit is wel heel erg vreemd en zou mogelijk een risico kunnen opleveren!

Verder is de partitieindeling wel goed, ongeveer zoals ZFSguru doet. Juiste start offset (2048 = 1024K = 1MiB) en ook padding aan het einde van de disk (LBA 5860515840 tot 5860532224 + 911).

[dcm360]

CiPHER: Kan je ook nog aantonen dat ZoL partities aanmaakt en vervolgens aan de gang gaat zonder zich daar aan te houden? In dat geval snijdt het nog een beetje hout, anders zit het verhaal er wel weer aardig naast...

[staticint]

Bedankt voor de reacties

Ik ben net even verder aan het pluizen geweest. Volgens mij wordt de ZFS partitie(in dit geval een OS X ZFS partitie GUID blijkbaar) wel gebruikt. In de zpool status staat namelijk diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYVp1, welke zou moeten verwijzen naar LBA2048 volgens mij...

Als ik een gpart show -l doe hebben ze allemaal als gpt-label "zfs"

Kan ik die labels aanpassen zonder risico? (wederom interesse, moet nog even een nachtje slapen over hoe erg ik ga OCD'en hierop )

[Verwijderd]

FreeBSD pakt de DISKID en de pool is online. Dus ZFS moet de disk beginnend bij de offset van de DISKID als een ZFS disk herkennen. Dus dit lijkt te werken.

Vervolgens zie ik deze partitielayout:

code:

=>        34  5860533101  diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYV  GPT  (2.7T)
          34        2014                                              - free -  (1.0M)
        2048  5860513792                                           1  !6a898cc3-1dd2-11b2-99a6-080020736631  (2.7T)
  5860515840       16384                                           9  !6a945a3b-1dd2-11b2-99a6-080020736631  (8.0M)
  5860532224         911                                              - free -  (456K)

Daar staat heel duidelijk dat de diskid op LBA34 begint en lengte 5860533101 heeft (dus 34 tot 5860533135).

Dat zou betekenen dat de ZFS data begint vóór de eerste GPT partitie en eindigt ná de de laatste GPT partitie. Dat is wel erg vreemd!

Wat hij zou kunnen proberen is: 'zpool import -d /dev/gptid'. Als het klopt wat ik denk/zeg, zou ZFS daar geen importable pool moeten kunnen vinden....

[Verwijderd]

staticint schreef op woensdag 26 augustus 2015 @ 23:02:
Volgens mij wordt de ZFS partitie(in dit geval een OS X ZFS partitie GUID blijkbaar) wel gebruikt. In de zpool status staat namelijk diskid/DISK-%20%20%20%20%20WD-WCC4N22A7AYVp1, welke zou moeten verwijzen naar LBA2048 volgens mij...

Ahhhh, dan heb je beter gekeken dan ik. En p1 betekent inderdaad de eerste GPT partitie.

Dan klopt het gewoon allemaal en kun je mijn berichtjes als niet verzonden beschouwen.

Kan ik die labels aanpassen zonder risico? (wederom interesse, moet nog even een nachtje slapen over hoe erg ik ga OCD'en hierop )

Ja je kunt doen:

zpool export <poolname>
zpool import -d /dev/gpt/ <poolname>

Als je geen GPT labels hebt, kun je nog GPTIDs gebruiken:

zpool import -d /dev/gptid/ <poolname>

Je kunt ook eerst GPT labels toekennen, en daarna importeren op de GPT labels.

[staticint]

Toppers! Bedankt

In eerste instantie vind dit soort dingen toch altijd een beetje eng, vandaar de vragen Vooral het omzetten van Debian naar BSD. Maar goed, daar hebben ze oefenen in een VM voor uitgevonden geloof ik. Ik ga er morgen mee aan de slag in ieder geval.

[FireDrunk]

Als ik binnenkort een keer tijd over heb, zal ik eens kijken hoe die disk labels zich weerhouden als je daar flink in ga rammelen onder ZoL
Wel een leuke test qua "robuustheid".

[Bigs]

Zo belangrijk zijn die labels / ids toch niet? Bij een import verzamelt zfs gewoon alle block devices die hij kan vinden en kijkt of daar een ZFS structuur op staat. Als hij genoeg block devices voor een bepaalde pool vindt wordt die geimporteerd. Hoe de GPT partities of de onderliggende devices heten is voor ZFS niet interessant. Al dat ge'import -d hierboven is puur voor het uiterlijk Als je geen -d opgeeft vindt ZFS het zelf wel uit.

[FireDrunk]

Lol, dat is wel iets te voorbarig hoor... Als je geen -d mee geeft, zoekt ZFS standaard in /dev/
Daar in zitten bepaalde standaard directories, en ZFS kijkt gewoon per 'block' device wat *daar* staat...

ZFS heeft zelf geen logica om block devices uit te lezen via de kernel...

[Verwijderd]

Het punt is niet importeren. Dat gaat wel goed. Het punt is als je pool al geïmporteerd is, maar je gaat de disk onder een andere noemer beschikbaar stellen. Dat betekent dat het 'welke disk hoort bij ZFS' verhaal niet alleen eenmalig tijdens de import moet gebeuren en vanaf dat moment betrekt het de gegevens vanaf de zpool.cache file, maar dat betekent dat ZoL net als BSD tijdens elke boot alle devices en alle partities op alle devices moet scannen welke disk bij welke ZFS pool hoort. Dat was het punt.

[FireDrunk]

Misschien leuk voor jullie beiden:

De daadwerkelijke (default) scripts om pools tijdens boot te importeren:
https://github.com/zfsonl.../etc/init.d/zfs-import.in

En hier de daadwerkelijke default directories:
https://github.com/zfsonl...zfs/libzfs_import.c#L1041

GPT partitielabels komen in /dev/by-partlabel/ en valt dus niet onder de default gescande directories.

/dev/by-label/ zijn filesystem labels.

[ Voor 17% gewijzigd door FireDrunk op 27-08-2015 13:07 ]

[begintmeta]

Volgens mij zijn /dev/disk/by-label filesystemlabels, echt labelen van disks is volgens mij niet mogelijk (behoudens natuurlijk door aanpassen van udev-regels en standaard in by-id en by-path)

[ Voor 58% gewijzigd door begintmeta op 27-08-2015 13:02 ]

[FireDrunk]

I stand corrected

[FireDrunk]

Ik heb mijn ZFS Platform Comparison weer eens geupdate:

https://docs.google.com/s...gxPd2dbI/edit?usp=sharing

Mochten mensen nog commentaar hebben, laat het maar horen

[Verwijderd]

Zeker, maar even een ander idee: ik had een iets mooier HTML-based versie van jouw overzicht gemaakt. Is het niet leuk om een website te maken waarbij we dit presenteren, en ook alle keuzes argumenteren, en dus ook alle wijzigingen/mutaties zoals op een Wiki?

Lijkt me wel leuk om eens wat te doen met die comparison, behalve bijwerken terwijl niemand hem ziet. Hij zou ook goed gebruikt kunnen worden voor het nieuwe ZFS platforms topic, specifiek voor FreeNAS/NAS4Free/ZFSguru/napp-it, enzovoorts.

[BartNL]

ben ook wel benieuwd hoe je dan tot SMB speed bijna overal good tot excellent komt terwijl driver ondersteuning onder FreeBSD voor 10Gb beperkt lijkt. Of misschien dat driver support nog een aanvulling zou kunnen zijn?

[Verwijderd]

Wat ondersteunt BSD dan niet voor 10G adapters? De meeste gebruiken Intel 10G adapter en die werken gewoon, InfiniBand van Mellanox werkt, SolarFlare heeft goede drivers voor zijn 10G spul in BSD zitten. Verder ken ik niet zoveel merken en adapters. Wat mist er precies?

De driver-ondersteuning voor BSD is eigenlijk best goed, alleen op Wireless gebied en op Grafisch gebied loopt BSD sterk achter op Linux. De rest valt het echt mee naar mijn idee. Wel is het zo dat netwerkadapters iets later worden toegevoegd en dan moet je -STABLE of -CURRENT draaien, of de allerlaatste -RELEASE. Distributies zoals FreeNAS draaien veelal een iets oudere versie, waardoor die minder goede hardwareondersteuning heeft. Maar dat mag je FreeBSD zelf niet aanrekenen.

[ Voor 47% gewijzigd door Verwijderd op 28-08-2015 13:00 ]

[CurlyMo]

Commentaar op jou lijst:
- Waarom wel apart Linux en geen FreeBSD?
- Wat bedoel je met een "bad" ZFS import / export?
- Waarom is de ene keer een blok grijs en de andere keer rood.
- Addon support is nogal subjectief net als standaard veiligheid.

Tijd dus voor onafhankelijke input

[Verwijderd]

Bedoel je mijn lijst of die van FireDrunk? Mijn lijst is ook gebaseerd op het laatste lijstje wat FireDrunk destijds had gemaakt.

Ik denk dat ZFS platforms worden besproken, niet zozeer operating systems die ZFS kunnen draaien. Maar storage platforms. Linux zou eigenlijk vervangen moeten worden door een op Linux-gebaseerd ZFS platform. FireDrunk's ZFSMond zou eigenlijk best wel geschikt kunnen zijn, mits dit verder ontwikkeld wordt.

[ Voor 17% gewijzigd door Verwijderd op 28-08-2015 13:02 ]

[FireDrunk]

@CurlyMo, kijk even naar mijn laatste variant op Google Docs. Ik zou zeer verheugd zijn als jij updates hebt! Samen weten we immers meer!

@CiPHER, dat omzetten kan prima, eerst samen editen in Google Docs, daarna kunnen we hem altijd nog omzetten naar HTML... HTML is statisch, Google Docs is dynamisch

[CurlyMo]

Zet je update mogelijkheid maar aan.

[Compizfox]

FireDrunk schreef op vrijdag 28 augustus 2015 @ 12:28:
Ik heb mijn ZFS Platform Comparison weer eens geupdate:

https://docs.google.com/s...gxPd2dbI/edit?usp=sharing

Mochten mensen nog commentaar hebben, laat het maar horen

Waarom heeft ZFSGuru "Average to Good (Quality varies)" packages en FreeNAS "Good"? Bij ZFSGuru kun je de Ports tree gebruiken, volgens mij bij FreeNAS niet

Of beperk je je alleen tot de Services? In dat geval zou ik dat er even bij zetten ("Packages via webinterface" of iets dergelijks)

[Verwijderd]

Ik heb in mijn lijstje addon quantity en addon quality. Dus het kan zijn dat FreeNAS minder addons heeft, maar gemiddeld wel van hogere kwaliteit. Bij ZFSguru zijn er een boel addons die alleen packages installeren, maar je zelf moet configureren. Apache bijvoorbeeld; zit geen web-interface bij om dit te configureren. Zodoende kan de kwaliteit per addon sterk verschillen. Ik denk dat dit minder het geval is bij de overige platforms.

@FireDrunk: punt is ook dat mijn lijstje flink uitgebreid is en denk ik ook een betere indeling heeft met hoofdstukjes. Dat mis ik een beetje in jouw lijstje. En HTML kun je via wiki toch ook dynamisch maken?

[FireDrunk]

Compizfox schreef op vrijdag 28 augustus 2015 @ 13:18:
[...]

Waarom heeft ZFSGuru "Average to Good (Quality varies)" packages en FreeNAS "Good"? Bij ZFSGuru kun je de Ports tree gebruiken, volgens mij bij FreeNAS niet

Of beperk je je alleen tot de Services? In dat geval zou ik dat er even bij zetten ("Packages via webinterface" of iets dergelijks)

Dat blijft een lastig punt. Onder Linux heb je ook niet echt packages via een webinterface, maar wel losse installers die veel beter werken dan packages van ZFSguru (zoals bijvoorbeeld LaSi.sh)

CurlyMo schreef op vrijdag 28 augustus 2015 @ 13:18:
Zet je update mogelijkheid maar aan.

Done

Verwijderd schreef op vrijdag 28 augustus 2015 @ 13:34:
@FireDrunk: punt is ook dat mijn lijstje flink uitgebreid is en denk ik ook een betere indeling heeft met hoofdstukjes. Dat mis ik een beetje in jouw lijstje. En HTML kun je via wiki toch ook dynamisch maken?

Allemaal waar, maar die indeling kunnen we altijd alsnog toevoegen als het lijstje inhoudelijk correct is.

[ Voor 21% gewijzigd door FireDrunk op 28-08-2015 14:10 ]

[Verwijderd]

Je kunt het zo doen:
- addons via official channel:
- addons via operating system:

Bij FreeNAS en NAS4Free kun je dan zeggen dat het 2e dus via het OS, maar beperkt of niet mogelijk is, of niet officiëel wordt ondersteund, omdat het een gestripte distributie is op basis van NanoBSD.

Bij Linux kun je zeggen geen officiële addons, maar via het OS is het wel 'excellent' terwijl ik bij BSD 'good' zou geven - de portstree is niet zo goed en uitgebreid als bij Linux distributies.

[FireDrunk]

Staat er in.

[BartNL]

Verwijderd schreef op vrijdag 28 augustus 2015 @ 12:58:
Wat ondersteunt BSD dan niet voor 10G adapters? De meeste gebruiken Intel 10G adapter en die werken gewoon, InfiniBand van Mellanox werkt, SolarFlare heeft goede drivers voor zijn 10G spul in BSD zitten. Verder ken ik niet zoveel merken en adapters. Wat mist er precies?

ik gebruik Intel X540-T2 adapters en wanneer ik server onder Windows draai wordt ik bij kopieren naar de server beperkt door SSD en haal ik 500 MB/s via netwerk. Doe ik datzelfde met exact dezelfde hardware via SMB onder FreeBSD dan kom ik tot 180 MB/s. Dat is voor een 10 Gb verbinding niet goed. De netwerkkaart werkt wel.
Het kan aan Samba liggen of aan FreeBSD maar resultaat is dat een Samba share te traag is.
Huidige ZFSGuru tuning pagina is overigens wel ideaal voor deze testen

[jacovn]

Ik krijg er tot 350 MB/sec naar toe. Andere kant op (server naar pc) is 100 ?

[Verwijderd]

@BartNL: Hier kun je zien dat iemand met Intel X520 adapter onder ZFSguru wel goede snelheden haalt: http://zfsguru.com/forum/zfsperformance/949.

[BartNL]

het zou de Samba implementatie kunnen zijn, zie dat downloadski die snelheid alleen haalt met mbuffer en meldt met NFS ook maar 150 MB/s te halen?

[HyperBart]

Was jij dat die al eens getest had met iperf enzo om dingen uit te sluiten?

[BartNL]

wel met iperf, en daarmee lijkt netwerk de bottleneck onder Freebsd d.w.z. kom maar net boven de 1 Gb/s terwijl ik met dezelfde server voorzien van Windows bijna 10Gb/s haal. De tijd ontbreekt me nog om structureel te testen.

In de ZFSGuru server zitten twee shares waarvan 1x een enkele SSD en de andere een 12 disk raidz2 array. Met beide arrays haal ik bij reads en writes dezelfde snelheid 180 MB/s. Op zich vreemd aangezien beide shares in theorie veel sneller zouden moeten zijn en ik ook zou verwachten dat reads sneller zijn dan writes.

Vind het ook raar dat bij zware kopieer actie er geen cache of buffer gebruikt lijkt te worden en Kernel langzaam steeds meer geheugen gebruikt?


CPU E5-2603 zit wel boven de 50%


Wat mij betreft lijkt het er op dat netwerk performance slecht is. Vandaar dat ik ook een andere netwerk kaart wil proberen.

[ Voor 74% gewijzigd door BartNL op 28-08-2015 23:46 ]

[jacovn]

Ik betwijfel of het aan je netwerk laag ligt..
Met zfs send/receive en mbuffer kun je bijna line rate doen met een pool met 10 disks in raid-z2.
NFS lukte tot 150-160MB/sec per sessie, met 2 sessies was het 300 MB/sec

Met iperf moet je ook veel meer kunnen halen dan 100 MB/sec.
Maar met smb vanaf een PC valt het inderdaad wat tegen. Het enige wat bij mij hielp was wat tuning aan de windows kant, en vanaf pc naar zfsguru server heb ik copy snelheden gezien die tegen de grens van mijn PC zijn I/O systeem zaten (350 mb/sec vanaf rai-5 volume)


En cpu belasting in zfsguru is niet zoals je verwacht. Ik heb er wel eens 500% zien staan...

[Verwijderd]

BartNL schreef op vrijdag 28 augustus 2015 @ 23:16:
wel met iperf, en daarmee lijkt netwerk de bottleneck onder Freebsd d.w.z. kom maar net boven de 1 Gb/s

Dan is dat al niet goed lijkt me. Als je netwerkperformance al niet goed is, dan zal de rest ook niet goed zijn. Je zal je eerst op de netwerkperformance moeten richten om het probleem uit te schakelen. Pas als je daar 9Gbps+ haalt, kun je door naar de volgende horde.

Wat je kunt proberen:
- iperf met grotere window size (wat is je performance dan?)
- checksum en TSO uitschakelen op je netwerkadapter
ifconfig ixgbe0 -rxsum -txsum -tso -tso4
- Jumbo frames gebruiken op zowel client als server
ifconfig ixgbe0 mtu 16000

En vooral ook: test met een andere client. Wat zou je halen als je van BSD naar BSD gaat met twee dezelfde adapters. Dat zijn ook goede tests denk ik. Misschien is Windows ook wel een factor of specifiek de combinatie Windows + FreeBSD.

Vind het ook raar dat bij zware kopieer actie er geen cache of buffer gebruikt lijkt te worden en Kernel langzaam steeds meer geheugen gebruikt?

ZFS gebruikt kernel geheugen; dus alles wat je daar ziet minus een paar honderd MB, is in gebruik door ZFS.

'cache' is ouderwets VFS cache, dus UFS filesystemen. buffers zijn o.a. write buffers maar jij gebruikt mogelijk Sendfile en dan heb je dat niet. Sendfile tracht om de gegevens maar één keer in RAM te laten staan, en dus memory copies te vermijden. Dus ZFS zet het één keer in het geheugen voor Samba bijvoorbeeld, en Samba wil die file via het netwerk sturen, dan zorgt Sendfile ervoor dat er direct vanaf de originele locatie via het netwerk verstuurd wordt, zonder weer extra memory copies te introduceren die performance beperken.

CPU E5-2603 zit wel boven de 50%

CPU usage is niet accuraat - het is in feite load. 100% betekent 1.00 en dat betekent dat een programma gemiddeld één wait state moet wachten voordat het de CPU kan gebruiken. Dit heb je typisch als je één proces hebt dat 100% CPU gebruikt op één core.

[BartNL]

ik twijfel ook maar het lijkt mij dat andere oorzaken afvallen.
Met verschillende ZFS pools haal ik dezelfde 180 MB/s van en naar o.a. een enkele SSD.
Zet ik i.p.v. ZFS een Windows installatie op dezelfde server zet haal ik 500MB/s naar dezelfde SSD.
Dingen die dan anders zijn zitten in de FreeBSD en ZFS kant. Aangezien de lees en schrijf snelheid bij verschillende pools gelijk is lijkt er mij een gemeenschappelijke oorzaak.
Meest logische lijkt nu de x540-t2 onder freebsd (o.a. omdat freenas niet zo positief is over intel) maar ik kan het best mis hebben

[Verwijderd]

Welke systeemversies heb je geprobeerd trouwens? Ook met 10.2 en 10.3?

[BartNL]

Verwijderd schreef op zaterdag 29 augustus 2015 @ 11:33:
Welke systeemversies heb je geprobeerd trouwens? Ook met 10.2 en 10.3?

code:

Powered by ZFSguru version 0.3.0
Running official system image 10.2.002 featuring FreeBSD 10.2-RELEASE with ZFS v5000.
Running Root-on-ZFS distribution.

is de versie die ik nu gebruik. Zoals aangegeven zijn de tuning opties in ZFSGuru handig om allerlei opties die ik google uit te proberen. Daarmee kom ik nu op de 180 MB/s. Nieuwere versies heb ik nog niet geprobeerd.

[Verwijderd]

Overweeg ook om een nieuw topic aan te maken, want ik vind het wel interessant om erachter te komen wat nu de oorzaak is van je te lage netwerkprestaties. Ook handiger dat alle informatie bij elkaar staat, en ontlast dit topic ook weer wat.

[Dadona]

Verwijderd schreef op zondag 16 augustus 2015 @ 16:52:
Ik raad sterk af dat je SMR-schijven neemt, en de pricewatch: Seagate Archive HDD v2 ST8000AS0002, 8TB is zo'n schijf. Nog best duur ook - SMR schijven zouden echt flink goedkoper mogen zijn dan PMR, maar dat is niet zo. Dus ik raad je met klem aan om in plaats van deze SMR-schijven voor de beste PMR-schijven te gaan. Dan kom je uit op deze: pricewatch: WD Green WD60EZRX - de beste schijf ooit in mijn bezit.

Toch even hierop terugkomen.
Allereerst ben ik het met je eens dat de schijf toch nog altijd duurder is dan gewenst en verwacht. En ze verbruiken ook iets meer dan ik had gehoopt. Echter, ik vind het niet meteen directe afraders, zeker met ZFS en caching.
Kijk ik even naar een 8TB versus een 6TB uit jouw voorbeeld en vertaal ik de 6TB naar 8TB (qua prijs) dan zit er een verschil tussen van 67 euro (de Green zou 309 euro kosten, de Archive kost 242 euro). Voor die prijs kun je net aan een m550 van 128GB kopen. Als je die nu even heel heftig vrijlaat (50%), een deel voor write cache pakt en nog een OS erbij zet dan heb je toch wel een leuke combinatie lijkt mij?
Je pakt de zwakke plek van de Archive aan, read is wel prima en je hebt je OS met programma's op een SSD. Natuurlijk is het verbruik van de Archive dan nog altijd hoger.
(En ja, je kunt natuurlijk ook een grotere SSD nemen die nog wat beter is enzovoort, maar het ging om het punt op zich. Een Archive met een SSD als combinatie.)

[riwi]

BartNL schreef op vrijdag 28 augustus 2015 @ 22:28:
het zou de Samba implementatie kunnen zijn, zie dat downloadski die snelheid alleen haalt met mbuffer en meldt met NFS ook maar 150 MB/s te halen?

Welke samba implementatie heeft FreeBSD dan? Want er is behoorlijk winst geboekt in de latere versies SMB3 kwa performance en CPU load. Het maakt ook uit welke windows versie je hebt (win7 heeft nog oude SMB2) vanaf 8 / 8.1 is er SMB3.

Ik merk met mijn ZoL wel voordeel van de SMB3 door de "server-side-copy" feature van SMB3.
Als ik met windows een copy/move doe van het ene ZFS filesystem naar een ander ZFS filesystem binnen dezelfde pool dan gaat de data niet over het netwerk maar kopieert SMB het op de server lokaal.
De client waarmee je de kopieer opdracht geeft moet dan wel SMB3 compatible zijn (dus win8 of hoger, of in mijn geval win7 met total commander).

Daarnaast heb ik wel in de smb.conf op de linux zijde de socket options (send en receive buffers) verhoogd :
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=262144 SO_SNDBUF=262144
Dat scheelde bij mij wel in positieve zin (om de gbit te vullen).

Ik hoorde in een ZFS presentatie van Matt Ahrens dat ze het fenomeen onderkennen dat mbuffer performance verhogend werkt bij send/receive en dat ze er aan werken om ZFS send en receive zo te verbeteren dat mbuffer niet langer nodig zal zijn. Het was een 'relatively easy fix' zei hij, maar zal wel een half jaar duren voor het downstream in alle linux/BSD/etc. platformen terecht gekomen is.

[Compizfox]

riwi schreef op zondag 30 augustus 2015 @ 13:18:
[...]

Welke samba implementatie heeft FreeBSD dan? Want er is behoorlijk winst geboekt in de latere versies SMB3 kwa performance en CPU load. Het maakt ook uit welke windows versie je hebt (win7 heeft nog oude SMB2) vanaf 8 / 8.1 is er SMB3.

Je bedoelt SMB-implementatie SMB (aka CIFS) is de naam van het protocol. Samba is de naam van een implementatie (een SMB-server). Onder FreeBSD heb je ook Samba, net als onder Linux. Je kunt kiezen uit allerlei versies, van Samba 3.6.x tot 4.2.x.

Daarnaast heb ik wel in de smb.conf op de linux zijde de socket options (send en receive buffers) verhoogd :
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_KEEPALIVE SO_RCVBUF=262144 SO_SNDBUF=262144
Dat scheelde bij mij wel in positieve zin (om de gbit te vullen).

Ik gebruik zelf dit:

code:

socket options = IPTOS_LOWDELAY TCP_NODELAY

Mij is verteld dat die send- en receivebuffers automatisch getuned worden (bij FreeBSD iig). Handmatig overriden werkt dus meestal averechts.

Ik heb best wel een performanceboost gemerkt tussen Samba 3.x en 4.x. Met Samba 4.2 trek ik bijna gigabit vol (met grote files tenminste).

[HyperBart]

riwi schreef op zondag 30 augustus 2015 @ 13:18:
[...]

Ik merk met mijn ZoL wel voordeel van de SMB3 door de "server-side-copy" feature van SMB3.
Als ik met windows een copy/move doe van het ene ZFS filesystem naar een ander ZFS filesystem binnen dezelfde pool dan gaat de data niet over het netwerk maar kopieert SMB het op de server lokaal.
De client waarmee je de kopieer opdracht geeft moet dan wel SMB3 compatible zijn (dus win8 of hoger, of in mijn geval win7 met total commander).

Storage offloading à la ODX dus, maar dan met SMB3

[riwi]

Compizfox schreef op zondag 30 augustus 2015 @ 13:43:
Je bedoelt SMB-implementatie SMB (aka CIFS) is de naam van het protocol. Samba is de naam van een implementatie (een SMB-server). Onder FreeBSD heb je ook Samba, net als onder Linux. Je kunt kiezen uit allerlei versies, van Samba 3.6.x tot 4.2.x.

Inderdaad. De SMB implementatie. Ofwel de versie van het protocol, niet de software versie zelf.
CIFS is de oude naam en als je de SMB mensen moet geloven alleen synoniem voor versie 1.0 van het SMB protocol.
http://blog.varonis.com/the-difference-between-cifs-and-smb/

Ik merkte met de send en receive size in de socket options in ieder geval een directe verbetering toen ik die ophoogde. Dat was al wel een paar jaar geleden dus misschien is het met de huidige SMB implementatie op Linux ook niet meer nodig. Ik zal eens experimenteren met het weg halen van die waardes.

Heb PC-NAS1 en PC-NAS2 nu met dual gbit aangesloten op dezelfde cisco slm2008 en wil eens proberen wat voor snelheid er te halen is met zfs send/receive. Zonder mbuffer en met 1 gbit link zie ik in zpool iostat 110MB/sec op beide pools. Ik wil ongeveer 7TB overzetten dus hopelijk helpt 2x 1Gbit link een beetje.

En de nieuwe korte sata kabeltjes waren binnen (5x 10cm en 5x 20cm) :

[ Voor 5% gewijzigd door riwi op 30-08-2015 15:24 ]

[Compizfox]

riwi schreef op zondag 30 augustus 2015 @ 15:14:
[...]

Inderdaad. De SMB implementatie. Ofwel de versie van het protocol, niet de software versie zelf.

Wil niet lopen mierenneuken, maar volgens mij slaat een implementatie van een protocol toch echt op een stuk software dat dat protocol implementeert. Samba is dus een implementatie van het SMB-protocol, net zoals bijvoorbeeld FreeRADIUS een implementatie is van het RADIUS-protocol en Xorg een implementatie is van het X11-protocol.

Wat jij bedoelt, is gewoon de versie van het protocol.

Hoe dan ook, onder FreeBSD heb je gewoon dezelfde Samba als onder Linux. Als je Samba 4.x neemt heb je dus full SMB3-support.

CIFS is de oude naam en als je de SMB mensen moet geloven alleen synoniem voor versie 1.0 van het SMB protocol.
http://blog.varonis.com/the-difference-between-cifs-and-smb/

Aha, ik lees het. I stand corrected.

[ Voor 7% gewijzigd door Compizfox op 30-08-2015 15:53 ]

[riwi]

Compizfox schreef op zondag 30 augustus 2015 @ 15:51:
Wat jij bedoelt, is gewoon de versie van het protocol.

Dat bedoelde ik inderdaad en daarom schreef ik dat ook letterlijk

riwi schreef op zondag 30 augustus 2015 @ 15:14:
Inderdaad. De SMB implementatie. Ofwel de versie van het protocol, niet de software versie zelf.

Maargoed we bedoelen hetzelfde denk ik.

[jacovn]

Zit samba 4.x standaard in freebsd 10.2 of 11 ?

[CurlyMo]

Kies dan wel voor >= samba42-4.2.2_1 want de oudere versies hebben een voor mij cruciale bug in de crossrename module: https://lists.samba.org/a...cal/2014-June/100811.html

[Compizfox]

jacovn schreef op zondag 30 augustus 2015 @ 19:25:
Zit samba 4.x standaard in freebsd 10.2 of 11 ?

Ligt eraan wat je definitie van "standaard" is. Het zit natuurlijk niet in het basesystem, maar er zijn ports voor. De portstree staat los van de versie van het basesystem, dus het maakt niet eens uit welke FreeBSD je draait.

[ Voor 16% gewijzigd door Compizfox op 30-08-2015 20:28 ]

[Verwijderd]

CurlyMo schreef op zondag 30 augustus 2015 @ 19:49:
Kies dan wel voor >= samba42-4.2.2_1 want de oudere versies hebben een voor mij cruciale bug in de crossrename module: https://lists.samba.org/a...cal/2014-June/100811.html

De samba42 port zit op het moment op versie 4.2.3_1 dus dat lijkt me goed dan.

[BartNL]

Verwijderd schreef op zaterdag 29 augustus 2015 @ 11:57:
Overweeg ook om een nieuw topic aan te maken, want ik vind het wel interessant om erachter te komen wat nu de oorzaak is van je te lage netwerkprestaties. Ook handiger dat alle informatie bij elkaar staat, en ontlast dit topic ook weer wat.

zal ik doen, zit nu op 480 MB/s met configuratie van https://www.bsdforen.de/t...stirbt.30875/#post-260537.
Bij mij blijkt de smb.conf tot nu toe meeste verschil te maken. Heb daar nu via trial en error socket options de SO_SNDBUF en SO_RCVBUF op 425984 staan en dat lijkt tot nu toe beste. Wanneer ik deze waarde verdubbel kakt de boel weer in.
Er zit wel wat progres in maar zou toch minimaal 500MB/s willen halen en liefst bij lezen en schrijven. De 480MB/s haal ik nu alleen bij schrijven dus er is nog werk te doen

[ Voor 23% gewijzigd door BartNL op 30-08-2015 23:41 ]

[revox862]

Voor een nieuw ZFS build met RAIDZ2, 4x6TB of 6x4TB?

[ Voor 4% gewijzigd door revox862 op 30-08-2015 22:46 ]

[Compizfox]

revox862 schreef op zondag 30 augustus 2015 @ 22:46:
Voor een nieuw ZFS build met RAIDZ2, 4x6TB of 6x4TB?

Dat hangt er een beetje van af wat jij het belangrijkst vindt. Met 4x 6TB heb je (relatief) meer parity. 6x 4TB zal sneller zijn.

[revox862]

Nah, niets bijzonders. Mijn Linux ISO's opslaan via 1gpbs netwerk.