Het grote ZFS topic

[CurlyMo]

@FireDrunk, wat wil je precies veranderd zien in ZoL. Misschien kan ik wel helpen?

[ Voor 4% gewijzigd door CurlyMo op 04-02-2016 22:03 ]

[FireDrunk]

Druk ff op F5...

Zoals hier: https://github.com/zfsonl...zfs/libzfs_import.c#L1283
te lezen is, zit by-partlabel er niet in by default. Dus MOET je de cache file hebben, anders kan hij je disks dus nooit vinden.
Als je met custom disk labels zou werken, zou het dus wel werken. Maar we werken nou eenmaal allemaal graag met partities.

@CurlyMo, eigenlijk moet /dev/disk/* eerst gescanned worden, en /dev/* pas als last resort gebruikt worden. Bovendien zou de cachefile anders moeten werken ( geupdate worden met betere device nodes ).

Zie github linkje.

[Verwijderd]

Het zou fijn zijn als Linux gewoon devices scant in plaats van simpelweg aannemen dat ze beschikbaar zijn onder de laatste device node. Dus dat lijkt me een goede verandering. Eigenlijk zou de hele zpool.cache niet meer nodig moeten zijn, behalve om pools te herkennen die op dat moment niet zijn aangesloten, en zodra de device nodes er weer wel zijn, dat de pool automatisch geïmporteerd wordt. Dat gebeurt niet als het systeem de pool nog niet kent. Dat is denk ik de enige valide functie van de zpool.cache file. Voor de rest zou de 'device sensing' moeten gebeuren tijdens boot en tijdens het importeren van een pool (dus zowel 'zpool import' als 'zpool import <poolnaam>'

[FireDrunk]

Dat doet Linux dus ook allemaal, allen niet in /dev/disk/by-partlabel, maar wel in een heleboel andere directories (zoals ik al steeds zeg).

Juist *daarom* is die cache file zo belangrijk, daar staan namelijk de device nodes in voor pools met disks in niet default locaties.

Vergelijk het met een pool van files in /root/ die je exporteert. Als je daarna een import doet, gaat ZFS ook op FreeBSD niet op magische wijze de files in /root/ vinden, tenzij ze in de zpool.cache file staan.

Zo moet je ook kijken naar /dev/disk/by-partlabel/.

Zal eens een voorstel doen om /dev/disk/by-partlabel er in te krijgen, dat scheelt al de helft.

[ Voor 8% gewijzigd door FireDrunk op 04-02-2016 22:07 ]

[CurlyMo]

Het toevoegen van "/dev/disk/by-partlabel" is natuurlijk simpel. Het is dus complexer dan dat

[FireDrunk]

Ja en nee. Als /dev/disk/by-partlabel eerst zou komen, is het simpel. Het is complexer voor het uitlezen van de cache file en het vinden van dezelfde pool op andere nodes (by-id vs by-partlabel).

Daar is het meer voorkeur (wil je de pool terugzien onder by-id na een import/export of als by-partlabel).

[Verwijderd]

FireDrunk schreef op donderdag 04 februari 2016 @ 22:03:
Zoals hier: https://github.com/zfsonl...zfs/libzfs_import.c#L1283
te lezen is, zit by-partlabel er niet in by default. Dus MOET je de cache file hebben, anders kan hij je disks dus nooit vinden.

Alle device nodes onder /dev zouden in het search path moeten zijn; ook device nodes die van te voren niet zijn te voorspellen. Dus niet hardcoded /dev/by-partlabel in je code, maar dynamisch alle device nodes afscannen zoals bij BSD gebeurt. BSD herkent ook prima een encrypted node met .eli suffix bijvoorbeeld. Hardcoded erin prutsen lijkt mij maar 'hackerig' en niet een elegante oplossing zoals onder BSD werkt.

Als je dingen wilt veranderen voor ZoL, lijkt mij dat de manier hoe BSD werkt met device nodes en device tasting wel een inspiratie kan zijn.

Als je met custom disk labels zou werken, zou het dus wel werken. Maar we werken nou eenmaal allemaal graag met partities.

Nou al zou de disk/partitie label niet gevonden worden, dan kan hij toch terugvallen op de device node? /dev/sda1 bijvoorbeeld? De eerste partitie op de eerste disk, dus. Dat moet toch *altijd* werken als er geen enkele disk ID of partitie ID of partitie label device node wordt gevonden?

Mijn voorkeur zou hebben:
1) eerst scannen naar partitie LABELs, omdat die door de gebruiker zijn gekozen wat beter is dan een door de machine gegenereerde ID.
2) dan de GPT ID zodat nog steeds naar een partitie wordt verwezen en niet expliciet naar een fysieke schijf
3) dan de Disk/Device ID, zodat je wel naar een fysieke schijf verwijst maar deze prima kan wisselen qua kabel omdat dit de ID niet doet veranderen
4) als laatste, fallback naar de ruwe device node, dus /dev/sda1 bijvoorbeeld.

[CurlyMo]

FireDrunk schreef op donderdag 04 februari 2016 @ 22:09:
Ja en nee. Als /dev/disk/by-partlabel eerst zou komen, is het simpel. Het is complexer voor het uitlezen van de cache file en het vinden van dezelfde pool op andere nodes (by-id vs by-partlabel).

Ik zie niet in waarom dat moeilijker zou zijn.

code:

# ls -Al /dev/disk/by-id/
lrwxrwxrwx 1 root root  9 Feb  4  2016 ata-BHYVE_SATA_DVD_ROM_BHYVE-C867-6EF9-B1                                     96 -> ../../sr0
# ls -Al /dev/disk/by-label/
lrwxrwxrwx 1 root root 9 Feb  4  2016 Ubuntu-Server\x2014.04.1\x20LTS\x20amd64 -> ../../sr0

Je kunt a.d.v. de symlink in de by-id en in de by-label natuurlijk gewoon de match vinden.

[FireDrunk]

@CiPHER,

De 1) manier is niet de Linux manier. Partitielabels is niet iets wat veel gebruikt wordt in de Linux wereld. UUID's zijn veel 'gewoner' (zowel grub als EFI werken daar vaker mee).
2) Er is niet zoiets als een GPT ID, dat is iets wat BSD volgens mij zelf genereert adhv info over de device node en de partitienaam (daarom kan je in BSD ook duplicate partitielabels hebben).
3) dat is dus /dev/disk/by-id/
4) is logisch.

Overigens ben ik het ook deels gewoon met je eens dat de BSD scan manier beter is, maar er moet nog wel rekening gehouden worden met non-udev systemen. (ja ja, die zijn er ook...)

@CurlyMo, klopt, dat is ook wel wat ryao zegt dat zijn plan as (/dev/disk/by-id doorzoeken en kijken of er eventueel symlinks zijn in /dev/disk/by-partlabel)

ik heb zojuist geforked, even kijken of ik iets kan brouwen

[ Voor 13% gewijzigd door FireDrunk op 04-02-2016 22:15 ]

[Verwijderd]

FireDrunk schreef op donderdag 04 februari 2016 @ 22:14:
De 1) manier is niet de Linux manier. Partitielabels is niet iets wat veel gebruikt wordt in de Linux wereld. UUID's zijn veel 'gewoner' (zowel grub als EFI werken daar vaker mee).

Des te meer reden om deze bovenaan in de lijst van te scannen nodes te zetten. Als ze toch worden gebruikt, betekent dit dat de gebruiker expliciet labels heeft toegewezen aan de partities. Grote kans dat de gebruiker deze dan ook wilt gebruiken. Wat is er beter dan een zelfgekozen partitielabel te gebruiken in plaats van een ID waar user-error op de loer ligt? Als de gebruiker hier anders over dacht, had hij wellicht ook geen label toegekend aan de partitie, omdat dit optioneel is.

2) Er is niet zoiets als een GPT ID, dat is iets wat BSD volgens mij zelf genereert adhv info over de device node en de partitienaam (daarom kan je in BSD ook duplicate partitielabels hebben).

Elke GPT partitie heeft toch een eigen identificatiecode (ID)? Ongeacht welk OS je gebruikt? Als je zelf geen labelnaam hebt toegewezen aan een partitie, dan heb je nog altijd een GPT ID. Volgens mij geldt dat ook voor andere operating systems en is dit inherent aan hoe GPT gespecificeerd is. Maar dat is een aanname van mijn kant.

Als dat klopt, zou Linux naast /dev/disk/by-id en /dev/disk/by-label ook eenzelfde systeem voor partities kunnen hebben: /dev/part/by-id en /dev/part/by-label. Lijkt mij de meest logische oplossing.

[FireDrunk]

Verwijderd schreef op donderdag 04 februari 2016 @ 22:22:
[...]

Des te meer reden om deze bovenaan in de lijst van te scannen nodes te zetten. Als ze toch worden gebruikt, betekent dit dat de gebruiker expliciet labels heeft toegewezen aan de partities. Grote kans dat de gebruiker deze dan ook wilt gebruiken. Wat is er beter dan een zelfgekozen partitielabel te gebruiken in plaats van een ID waar user-error op de loer ligt? Als de gebruiker hier anders over dacht, had hij wellicht ook geen label toegekend aan de partitie, omdat dit optioneel is.

In mijn fork staat hij ook als 2e (na /dev/by-vdev, wat dus een keiharde custom regel is in een losse vdev config file).

[...]

Elke GPT partitie heeft toch een eigen identificatiecode (ID)? Ongeacht welk OS je gebruikt? Als je zelf geen labelnaam hebt toegewezen aan een partitie, dan heb je nog altijd een GPT ID. Volgens mij geldt dat ook voor andere operating systems en is dit inherent aan hoe GPT gespecificeerd is. Maar dat is een aanname van mijn kant.

Dat is er, maar dat is een GUID, niet een ID. Niet echt 'human-readable'. Maar inderdaad, het zou kunnen.

Als dat klopt, zou Linux naast /dev/disk/by-id en /dev/disk/by-label ook eenzelfde systeem voor partities kunnen hebben: /dev/part/by-id en /dev/part/by-label. Lijkt mij de meest logische oplossing.

Die zijn er gewoon

[thijs@carbon ~]$ sudo ls /dev/disk/ -lah
total 0
drwxr-xr-x  9 root root  180 Feb  3 09:22 .
drwxr-xr-x 20 root root 3.2K Feb  4 22:04 ..
drwxr-xr-x  2 root root  200 Feb  3 09:22 by-id
drwxr-xr-x  2 root root   80 Feb  3 09:22 by-label
drwxr-xr-x  2 root root  100 Feb  3 09:22 by-partlabel
drwxr-xr-x  2 root root  100 Feb  3 09:22 by-parttypeuuid
drwxr-xr-x  2 root root  100 Feb  3 09:22 by-partuuid
drwxr-xr-x  2 root root  120 Feb  3 09:22 by-path
drwxr-xr-x  2 root root  100 Feb  3 09:22 by-uuid

--

Ik heb nu dit in mijn fork:

C:

zpool_default_import_path[DEFAULT_IMPORT_PATH_SIZE] = {
    /* Custom hard rules */
    "/dev/disk/by-vdev",    /* Custom rules, use first if they exist */
    "/dev/mapper",      /* Use multipath devices before components */

    /* Partitions > Devices */
    "/dev/disk/by-partlabel", /* Single unique entry set by user, always better than generated */
    "/dev/disk/by-partuuid", /* Single unique entry, persistant, and better than device id's */

    /* Devices (Custom Labeled)*/
    "/dev/disk/by-label",   /* Custom persistent labels */

        /* Devices (Generated) */
    "/dev/disk/by-uuid",    /* Single unique entry and persistent */
    "/dev/disk/by-id",  /* May be multiple entries and persistent */
    "/dev/disk/by-path",    /* Encodes physical location and persistent */

    /* Legacy Fallback */
    "/dev"          /* UNSAFE device names will change */
};

Denk dat dit de lading wel relatief goed dekt. Nu een pull request maken.

[ Voor 19% gewijzigd door FireDrunk op 04-02-2016 22:33 ]

[Verwijderd]

Ja UUID of GUID of wat dan ook - dat zijn allemaal door de computer gegeneerde IDs, dus daar doelde ik op. Dus we begrijpen elkaar denk ik wel.

Nouja kijk maar of je wat kunt veranderen, ik denk dat het een grote aanwinst zou zijn als Linux qua device sensing iets meer op BSD gaat lijken want daar werkt het eigenlijk bijna perfect. De enige verbetering van BSD zou zijn dat de GPTIDs eerst worden gescanned boven de GPT partitielabels. Dat is de reden dat ZFSguru de GPTIDs in zijn geheel heeft uitgeschakeld. Dat is geen groot probleem want als er geen partitielabels zijn dan valt BSD gewoon terug op de ruwe device nodes en dat is ook voor booten geen probleem.

Als Linux nog steeds problemen met booten zou hebben als de device nodes veranderen, is daarmee te leven. Maar een import moet toch echt 'gewoon' werken waarbij alle mogelijke devices nodes onder /dev worden gescanned en hoe dan ook de disk wordt gevonden. Handmatig opgeven met -d is echt nieuw voor mij, en als het nieuw voor mij is, kan ik me prima voorstellen dat mensen nieuw met ZFS daar helemaal problemen mee hebben. En 'corrupted data' is niet iets wat je graag ziet als ZFS gebruiker. Velen zullen ook denken dat dit permanent is, en de disks gewoon maar formatteren. Dat is natuurlijk helemaal van de zotte....

[FireDrunk]

Eens hoor!
Sowieso zou ik persoonlijk heel de /dev/sd* tree weglaten. Dat soort ouderwetse troep moeten ze gewoon eens uitfaseren.. Maar goed, wie ben ik

https://github.com/zfsonlinux/zfs/pull/4309
Helaas hebben ze (nog) geen automated tests geïntegreerd met GitHub, en ik heb ZFS nog nooit vanaf source gecompileerd en geïnstalleerd, dus kan het niet zo makkelijk testen... Scratch that, er loopt een test build.

http://build.zfsonlinux.o...20%28BUILD%29/builds/2926

Woops, en ik faal in C programmeren

[ Voor 51% gewijzigd door FireDrunk op 04-02-2016 22:45 ]

[CurlyMo]

@FireDrunk, is dit het doel (ruwe implementatie zonder nette memory management)?
http://pastebin.com/L5r92BMt

[maomanna]

heerlijk, een goede discussie los laten gaan.

Opzich zou de oplossing startpost worthy zijn?

momenteel aan t scrubben:

code:

 pool: datapool
 state: ONLINE
  scan: scrub in progress since Thu Feb  4 23:01:24 2016
    5,32G scanned out of 3,11T at 218M/s, 4h8m to go
    0 repaired, 0,17% done
config:

        NAME                      STATE     READ WRITE CKSUM
        datapool                  ONLINE       0     0     0
          raidz1-0                ONLINE       0     0     0
            DATAPOOL-A-CB903205   ONLINE       0     0     0
            DATAPOOL-B-BB13010    ONLINE       0     0     0
            DATAPOOL-C-CB903201   ONLINE       0     0     0
            DATAPOOL-D-BB13035    ONLINE       0     0     0
            DATAPOOL-E-M0H5LYHU2  ONLINE       0     0     0
        logs
          sLOG                    ONLINE       0     0     0
        cache
          L2ARC                   ONLINE       0     0     0

errors: No known data errors

Allemaal bedankt!! zonder jullie was t m niet geworden denk ik

[ Voor 3% gewijzigd door maomanna op 04-02-2016 23:03 ]

[FireDrunk]

CurlyMo schreef op donderdag 04 februari 2016 @ 22:57:
@FireDrunk, is dit het doel (ruwe implementatie zonder nette memory management)?
http://pastebin.com/L5r92BMt

Poeh, mijn C++ is erg roestig om dit zo even te evalueren.

[thijs@carbon testje]$ gcc curlymo.c 
curlymo.c: In function ‘main’:
curlymo.c:72:21: warning: implicit declaration of function ‘readlink’ [-Wimplicit-function-declaration]
         if((bytes = readlink(path1, link, PATH_MAX)) > 0) {
                     ^
[thijs@carbon testje]$ g++ curlymo.c 
curlymo.c:15:15: error: ‘::main’ must return ‘int’
 void main(void) {
               ^
curlymo.c: In function ‘int main()’:
curlymo.c:24:23: error: invalid conversion from ‘void*’ to ‘symlinks_t**’ [-fpermissive]
  if((symlinks = malloc(sizeof(struct symlinks_t *)*size)) == NULL) {
                       ^
curlymo.c:36:34: error: invalid conversion from ‘void*’ to ‘symlinks_t*’ [-fpermissive]
      if((symlinks[nrblk] = malloc(sizeof(struct symlinks_t))) == NULL) {
                                  ^
curlymo.c:40:39: error: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]
      if((symlinks[nrblk]->dev = malloc(strlen(file->d_name)+1)) == NULL) {
                                       ^
curlymo.c:49:35: error: invalid conversion from ‘void*’ to ‘symlinks_t*’ [-fpermissive]
       if((symlinks[size] = realloc(symlinks[size], sizeof(char *)*(size*2))) == NULL) {
                                   ^
curlymo.c:72:51: error: ‘readlink’ was not declared in this scope
         if((bytes = readlink(path1, link, PATH_MAX)) > 0) {
                                                   ^
curlymo.c:80:44: error: invalid conversion from ‘void*’ to ‘char**’ [-fpermissive]
            if((symlinks[i]->links = realloc(symlinks[i]->links, sizeof(char *)*(symlinks[i]->nrlinks+1))) == NULL) {
                                            ^
curlymo.c:84:65: error: invalid conversion from ‘void*’ to ‘char*’ [-fpermissive]
            if((symlinks[i]->links[symlinks[i]->nrlinks] = malloc(strlen(path1)+1)) == NULL) {
                                                                 ^

Als ik de code begrijp probeer je een array van symlinks te maken?
Volgens mij heeft zfsonlinux een heel aantal van jouw functies al, alleen niet op die manier genest.

https://github.com/zfsonl...zfs/libzfs_import.c#L1059

Check deze ook, daar staat hoe ze het nu doen.

[CurlyMo]

Je C++ is zo roestig om te zien dat dit niet eens C++ is, maar plain C:

code:

cc -o test test.c; ./test

[FireDrunk]

Lol, ik moet er echt weer eens aan gaan werken
(tis al laat )

test.c: In function ‘main’:
test.c:72:21: warning: implicit declaration of function ‘readlink’ [-Wimplicit-function-declaration]
         if((bytes = readlink(path1, link, PATH_MAX)) > 0) {
                     ^

[ Voor 65% gewijzigd door FireDrunk op 04-02-2016 23:09 ]

[CurlyMo]

Hier is de uitvoer overigens:

code:

cdrom [0]
sr0 [3]
- /dev/disk/../cdrom
- /dev/disk/by-label/Ubuntu-Server\x2014.04.1\x20LTS\x20amd64
- /dev/disk/by-id/ata-BHYVE_SATA_DVD_ROM_BHYVE-C867-6EF9-B196
dm-1 [3]
- /dev/disk/by-uuid/e8910ab9-2049-4ccc-ae8c-70804c52e79b
- /dev/disk/by-id/dm-uuid-LVM-XhV22PXT4oef02bOcBzrK9jA652ZPe06Niwps6XleoeHQUz6MZqfMgiASWqKv9kR
- /dev/disk/by-id/dm-name-ubuntu--vg-swap_1
dm-0 [3]
- /dev/disk/by-uuid/9915646a-3253-409a-b90e-91019cb5af7f
- /dev/disk/by-id/dm-uuid-LVM-XhV22PXT4oef02bOcBzrK9jA652ZPe06FblIU4KaJ5OGKq60DS7G1SLo3HhGN53I
- /dev/disk/by-id/dm-name-ubuntu--vg-root
vda5 [1]
- /dev/disk/by-id/virtio-BHYVE-4783-BDD5-21E3-part5
vda2 [1]
- /dev/disk/by-id/virtio-BHYVE-4783-BDD5-21E3-part2
vda1 [2]
- /dev/disk/by-uuid/83bad205-89fe-4cba-89fa-fb8c56493c0d
- /dev/disk/by-id/virtio-BHYVE-4783-BDD5-21E3-part1
vda [1]
- /dev/disk/by-id/virtio-BHYVE-4783-BDD5-21E3
loop7 [0]
loop6 [0]
loop5 [0]
loop4 [0]
loop3 [0]
loop2 [0]
loop1 [0]
loop0 [0]
ram15 [0]
ram14 [0]
ram13 [0]
ram12 [0]
ram11 [0]
ram10 [0]

[FireDrunk]

Hmm, dat is wel een goed begin inderdaad. Nu nog testen of iets een blockdevice is, en dan sorteren.
Top!

[CurlyMo]

Die test is er al op regel #35.

[FireDrunk]

Hmm, dan krijg je wel een hoop zooi mee... Als ik kijk hoe ZoL dat doet, zie ik weinig anders.
Zal wel kloppen op die manier.

ik zal morgen eens kijken of ik ZFS vanaf source kan compilen dan kunnen we het iets beter inbouwen.

[CurlyMo]

Leuk projectje Nu nog in de ZFS source krijgen. Dat is nog wel een uitdaging. Hij lekt wel als een gek nu

[Phyt_]

Helaas zojuist bij controle van mijn NAS.
Degrade Pool_1 , disk faulted.

code:

        NAME         STATE     READ WRITE CKSUM
        pool_1       DEGRADED     0     0     0
          raidz1-0   DEGRADED     0     0     0
            gpt/da5  ONLINE       0     0     0
            gpt/da1  ONLINE       0     0     0
            gpt/da2  ONLINE       0     0     0
            gpt/da3  ONLINE       0     0     0
            gpt/da4  FAULTED      1     1     0  too many errors
errors: No known data errors

Mijn smart # smartctl -a /dev/da4

code:

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_                                                                                                                                                             FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       -                                                                                                                                                                    162128616
  3 Spin_Up_Time            0x0003   092   092   000    Pre-fail  Always       -                                                                                                                                                                    0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -                                                                                                                                                                    2247
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -                                                                                                                                                                    0
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -                                                                                                                                                                    42394310
  9 Power_On_Hours          0x0032   083   083   000    Old_age   Always       -                                                                                                                                                                    15204
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -                                                                                                                                                                    0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -                                                                                                                                                                    45
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -                                                                                                                                                                    0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -                                                                                                                                                                    0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -                                                                                                                                                                    0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -                                                                                                                                                                    0 0 1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -                                                                                                                                                                    0
190 Airflow_Temperature_Cel 0x0022   066   055   045    Old_age   Always       -                                                                                                                                                                    34 (Min/Max 22/36)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -                                                                                                                                                                    0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -                                                                                                                                                                    35
193 Load_Cycle_Count        0x0032   092   092   000    Old_age   Always       -                                                                                                                                                                    17364
194 Temperature_Celsius     0x0022   034   045   000    Old_age   Always       -                                                                                                                                                                    34 (0 18 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -                                                                                                                                                                    0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -                                                                                                                                                                    0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -                                                                                                                                                                    0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -                                                                                                                                                                    1644h+27m+21.269s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -                                                                                                                                                                    14682213246035
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -                                                                                                                                                                    52555124385864

Wat mij nu niet duidelijk is of de dit nu een foutje is het systeem?
Aangezien de SMART niks aangeeft aan fouten, ik draai ZFSGURU, in de webinterface smart is alles OK en groen.
Op dit moment heb ik geen scrub draaien omdat ik niet weet of dit kan nu als hij faulted is?

Ik hoop dat jullie mij de juiste weg kunnen wijzen naar de mogelijke oorzaak/ oplossing(los van disk vervangen).

[Verwijderd]

Kijk naar de kernel log (Status->Logs->Kernel) of je daar iets vreemds ziet.

Verder: welke controller gebruik je? Aangezien je disks 'da' heten is dat geen ATA/AHCI controller.

Ten slotte; als je de SMART informatie post, post dan ook de daadwerkelijk nuttige gegevens; de RAW values waar het allemaal om draait, missen in je overzicht. Je hoeft ook geen -a te gebruiken wat een hoop onzingegevens produceert, alleen -A dus met een hoofdletter. Dan krijg je enkel de relevante SMART gegevens.

[maomanna]

Na het scrubben, er is niks gerepareerd, en geen errors meer. Problem fixxed!

[CurlyMo]

Voor alle duidelijk. Wat we willen is de zpool.cache onnodig maken. Dus bij het importeren van de pool moet van alle schijven duidelijk worden op welke verschillende manieren hij herkent kan worden. Van dezelfde schijf wil je dan de by-id, by-disklabel, by-label enz. weten. Vervolgens bepalen we dat als een schijf met een by-id te importeren is we die gebruiken, anders by-disklabel, by-label of als laatste redmiddel de /dev/? Dat laatste was dan wat @FireDrunk bedoelde je dan met de sortering van de symlink lijst.

[FireDrunk]

Precies, en wat mij betreft geeft het import commando ook gewoon een:

### Warning, detected the use of legacy device links (/dev/*), please be aware that this is an unsafe import method, please verify that udev rules are active for the population of /dev/disk/* directories for proper symlink detection ###

Ofzo

[CurlyMo]

Heb jij een lijstje met alle mogelijke /dev/disk/* en hun gewenste prio?

[FireDrunk]

Ik *denk* zoals ik hem gecommit heb in mijn pull request.

[CurlyMo]

Ga ik het geheel daarop aanpassen, opschonen en het op github zetten. Dan kunnen we daar verder discussieren

[ Voor 3% gewijzigd door CurlyMo op 05-02-2016 09:36 ]

[Phyt_]

Verwijderd schreef op vrijdag 05 februari 2016 @ 02:35:
Kijk naar de kernel log (Status->Logs->Kernel) of je daar iets vreemds ziet.

Verder: welke controller gebruik je? Aangezien je disks 'da' heten is dat geen ATA/AHCI controller.

Ten slotte; als je de SMART informatie post, post dan ook de daadwerkelijk nuttige gegevens; de RAW values waar het allemaal om draait, missen in je overzicht. Je hoeft ook geen -a te gebruiken wat een hoop onzingegevens produceert, alleen -A dus met een hoofdletter. Dan krijg je enkel de relevante SMART gegevens.

Excusses dat dit niet goed ging, het was al wat laat geworden :\.

code:

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   118   099   006    Pre-fail  Always       -       200911504
  3 Spin_Up_Time            0x0003   092   092   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   098   098   020    Old_age   Always       -       2249
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   076   060   030    Pre-fail  Always       -       42400696
  9 Power_On_Hours          0x0032   083   083   000    Old_age   Always       -       15215
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       45
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       0 0 1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   075   055   045    Old_age   Always       -       25 (Min/Max 22/36)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       35
193 Load_Cycle_Count        0x0032   092   092   000    Old_age   Always       -       17369
194 Temperature_Celsius     0x0022   025   045   000    Old_age   Always       -       25 (0 18 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       1644h+40m+19.639s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       14682213246035
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       52877052936837

Ik maak gebruik van de esxi en in passtrough mode IT flashed ibm m1015 controller.
Mij nu beetje onduidelijk wat ZFS ook verwacht om dit op te lossen / troubleshooten.
SMART is OK (?)
Scrub draaien ?

[Ultraman]

SMART ziet er OK uit.
Alleen aardig wat load cycles doordat de disk op standby gaat of de firmware de lees/schrijfkop in die stand zet. Geen direct issue daar te zien in ieder geval.

[Phyt_]

Klopt, ik heb ingesteld dat de harddisk's idd in standby gaan na x tijd.
Dit om het stroomverbruik in de perken te houden.

[FireDrunk]

17k is toch niet zo veel? Pas bij > 200k zou ik me druk maken.

[Phyt_]

Hier nog even de kernel log entries:
Hele VM host herstarten dan kijken of hij weer op komt, zou dat wat zijn ?

code:

(da5:mps0:0:4:0): SCSI sense: NOT READY asc:4,0 (Logical unit not ready, cause not reportable)
(da5:mps0:0:4:0): Retrying command (per sense data)
(da5:mps0:0:4:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 
(da5:mps0:0:4:0): CAM status: SCSI Status Error
(da5:mps0:0:4:0): SCSI status: Check Condition
(da5:mps0:0:4:0): SCSI sense: NOT READY asc:4,0 (Logical unit not ready, cause not reportable)
(da5:mps0:0:4:0): Error 5, Retries exhausted

nou ziet er niet lekker uit, lijkt wel een kernel panic te zijn geweest, disc is nu aan het resilveren.

code:

Feb  5 14:51:53 zfsguru syslogd: kernel boot file is /boot/kernel/kernel
Feb  5 14:51:53 zfsguru kernel: panic: bad pte va 802688000 pte 0
Feb  5 14:51:53 zfsguru kernel: cpuid = 0
Feb  5 14:51:53 zfsguru kernel: Uptime: 13d19h42m48s
Feb  5 14:51:53 zfsguru kernel: (da1:mps0:0:0:0): Synchronize cache failed
Feb  5 14:51:53 zfsguru kernel: (da2:mps0:0:1:0): Synchronize cache failed
Feb  5 14:51:53 zfsguru kernel: (da3:mps0:0:2:0): Synchronize cache failed
Feb  5 14:51:53 zfsguru kernel: (da4:mps0:0:3:0): Synchronize cache failed
Feb  5 14:51:53 zfsguru kernel: Copyright (c) 1992-2015 The FreeBSD Project.

Vreemd, hij is ineens klaar wel online maar wel met status fout..
Ik denk maar de spare disk plaatsen, ik kan alleen goede werkwijze vinden indien ik deze disk moet vervangen.

code:

  pool: pool_1
 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://illumos.org/msg/ZFS-8000-9P
  scan: resilvered 5.02G in 0h2m with 0 errors on Fri Feb  5 14:54:36 2016
config:

        NAME         STATE     READ WRITE CKSUM
        pool_1       ONLINE       0     0     0
          raidz1-0   ONLINE       0     0     0
            gpt/da5  ONLINE       0     0     0
            gpt/da1  ONLINE       0     0     0
            gpt/da2  ONLINE       0     0     0
            gpt/da3  ONLINE       0     0     0
            gpt/da4  ONLINE       0     0     2

errors: No known data errors

Maar eens nieuwe zfsguru 10.3.006 installeren als dit achter de rug is.

[ Voor 67% gewijzigd door Phyt_ op 05-02-2016 15:10 ]

[HyperBart]

Als je hier zoekt op mijn naam en "replace" en "degraded" dan vind je een (goede, althans dat denk ik toch ) uitleg hierover...

HyperBart in "Het grote ZFS topic"

[ Voor 20% gewijzigd door HyperBart op 05-02-2016 16:54 ]

[Ultraman]

FireDrunk schreef op vrijdag 05 februari 2016 @ 12:16:
17k is toch niet zo veel? Pas bij > 200k zou ik me druk maken.

Zou goed kunnen. Ik doe niet aan standby, voor mij lijkt het dan al snel veel

[narotic]

FireDrunk schreef op vrijdag 05 februari 2016 @ 12:16:
17k is toch niet zo veel? Pas bij > 200k zou ik me druk maken.

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   062    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   040    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   166   166   033    Pre-fail  Always       -       1
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       37
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   040    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   054   054   000    Old_age   Always       -       20573
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       37
191 G-Sense_Error_Rate      0x000a   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       17
193 Load_Cycle_Count        0x0012   001   001   000    Old_age   Always       -       1080524
194 Temperature_Celsius     0x0002   206   206   000    Old_age   Always       -       29 (Min/Max 18/39)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0
223 Load_Retry_Count        0x000a   100   100   000    Old_age   Always       -       0

Zelfs 200k hoeft niet perse een probleem te zijn

De reden hier is overigens dat dit een laptopschijf is die standaard extreem snel in standby gaat. Deze 1M is dus ook slechts bereikt in een relatief korte periode omdat ik niet direct doorhad dat mijn SAS2008 controller de camcontrol commando's niet doorgaf aan de schijven.

[Phyt_]

HyperBart schreef op vrijdag 05 februari 2016 @ 16:47:
Als je hier zoekt op mijn naam en "replace" en "degraded" dan vind je een (goede, althans dat denk ik toch ) uitleg hierover...

HyperBart in "Het grote ZFS topic"

Bedankt, nieuwe disk besteld, scrub geeft ook bult errors. WD 3tb BLue.

[CurlyMo]

@FireDrunk:
https://github.com/CurlyMoo/zfs-device-tasting

Zullen we daar verder ontwikkelen?

[FireDrunk]

Yes! al gecloned

[FireDrunk]

Soms komen antwoorden met een flinke vertraging :

On Sun, Nov 1, 2015 at 11:44 PM, Thijs Cramer <[e-mail]> wrote:
Hi guys,

Recently in a discussion online, i discussed the new Seagate 8TB SMR disks in combination with ZFS.
A big point that was undecided was: Can a SLOG help during rebuild of a bit SMR disk based array?

I know it's more risky to use the SLOG for resilver activities, but rebuilding sequentially could benefit these disks insanely. The problem with these disks is that under heavy load, the disk because very slow on random writes because of the SMR rewrites the disk has to do.

Can anyone answer whether it's currently beneficial to have a SLOG on an SMR disk array, or answer whether it's easy to adapt the code a bit to make this happen?

Antwoord van Matthew Ahrens

Currently, the ZIL (and thus log devices / SLOG) is not involved in resilvering. Therefore adding a SLOG device will have no impact on resilver speed. (Though I guess there could be secondary effects if adding the SLOG reduces fragmentation in the main devices.)

If you have a specific proposal for how the ZIL / SLOG could be used to accelerate resilvering, I can give you feedback on its feasibility.

--matt

[Q]

Leuk dat je antwoord hebt gehad, grappig dat een SLOG fragmentatie kan beperken, daar had ik nooit bij stil gestaan.

Over fragmentatie:

Mijn download server, een vergaar en test bak (een grote puinzooi) doet 'echter' maar 2% fragmentatie. Is fragmentatie onder het ZFS publiek hier een issue?

[ Voor 3% gewijzigd door Q op 09-02-2016 09:12 ]

[FireDrunk]

Soms

NAME        SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
VM_TIER_2   476G   162G   314G         -    72%    34%  1.00x  ONLINE  -
archive    21.8T  15.6T  6.20T         -     3%    71%  1.00x  ONLINE  -

[Verwijderd]

Als je veel mutaties hebt is de fragmentatie vrij hoog. Voor SSDs en goede L2ARC accelerated pools is dat niet zo'n probleem.

Als je pool meer WORM (Write-Once-Read-Many) is, zoals bij een archief/mediaserver, dan blijft je fragmentatie erg laag.

[HyperBart]

Ik vind 'm bij mij best hoog, voor een archief/mediaserver te zijn:

root@nas:~# zpool list
NAME        SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
EVO500      464G  76.0G   388G         -     2%    16%  1.00x  ONLINE  -
M4-STRIPE   357G   309G  48.1G         -    66%    86%  1.00x  ONLINE  -
stavanger  36.2T  20.7T  15.5T         -    18%    57%  1.00x  ONLINE  -

[dcm360]

Hm, als dat al veel moet zijn...

NAME      SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
storage  13.6T  8.58T  5.05T         -    31%    62%  1.00x  ONLINE  -
tank     8.12T  7.82T   316G         -    48%    96%  1.00x  ONLINE  -

[idef1x]

heeft fragmentatie nog invloed op je capaciteits gebruik? Als ik zo de bovenstaande voorbeelden bekijk lijkt het van wel?
Mijn ene server heeft een fragmentatie van 47% bij 86% capaciteit en de andere server een 29% fragmentatie bij 55% capaciteit. Zijn redelijk statische servers overigens.

[Q]

Op Reddit werd gewaarschuwd dat fragmentatie juist tijdens een resilver tot extra vertraging kan zorgen. Mogelijk dat dit die verhalen veroorzaakt van mensen die 50 uur op een rebuild zitten te wachten.

[dcm360]

De 50 uur rebuild die ik hier ooit eens heb geplaatst was niet op 1 van de 2 pools die in mijn vorige post staan, maar op deze met wat minder dramatische cijfers:

NAME   SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  7.25T  5.86T  1.39T         -    30%    80%  1.00x  ONLINE  -

[A1AD]

Welke firmware en bios gebruiken jullie voor de SAS2008 kaarten? Ik wil hem gaan gebruiken voor ZoL. Er staat nu fw:15.00.00.00 en bios: 07.29.00.00 op.

edit: ik heb er de P20 op geflashed

[ Voor 11% gewijzigd door A1AD op 10-02-2016 12:13 ]

[FireDrunk]

Ik zit op 19.

[u_nix_we_all]

A1AD schreef op woensdag 10 februari 2016 @ 11:54:
Welke firmware en bios gebruiken jullie voor de SAS2008 kaarten? Ik wil hem gaan gebruiken voor ZoL. Er staat nu fw:15.00.00.00 en bios: 07.29.00.00 op.

edit: ik heb er de P20 op geflashed

P20 schijnt buggy te zijn icm open source drivers, iedereen adviseert om op P19 te blijven.

[A1AD]

u_nix_we_all schreef op woensdag 10 februari 2016 @ 12:17:
[...]

P20 schijnt buggy te zijn icm open source drivers, iedereen adviseert om op P19 te blijven.

Ok, heb je zo snel even een download link? Ik vind enkel de P20

[u_nix_we_all]

A1AD schreef op woensdag 10 februari 2016 @ 12:26:
[...]


Ok, heb je zo snel even een download link? Ik vind enkel de P20

http://www.avagotech.com/...#tab-archive-drivers4-abc

Edit: en dan naar Downloads, Firmware , archive

Edit2: lijkt toch niet te werken bij die avago site, ik moet even zoeken of ik die firmware nog ergens heb

[ Voor 20% gewijzigd door u_nix_we_all op 10-02-2016 13:30 ]

[A1AD]

u_nix_we_all schreef op woensdag 10 februari 2016 @ 13:19:
[...]

http://www.avagotech.com/...#tab-archive-drivers4-abc

Edit: en dan naar Downloads, Firmware , archive

Edit2: lijkt toch niet te werken bij die avago site, ik moet even zoeken of ik die firmware nog ergens heb

Jep ik heb hem, in de file: 9211-8i_Package_P19_IR_IT_Firmware_BIOS_for_MSDOS_Windows zit wat we nodig hebben, thanks

[u_nix_we_all]

A1AD schreef op woensdag 10 februari 2016 @ 13:46:
[...]


Jep ik heb hem, in de file: 9211-8i_Package_P19_IR_IT_Firmware_BIOS_for_MSDOS_Windows zit wat we nodig hebben, thanks

OK, succes. Voor ZFS kun je het best de IT versie gebruiken, minder overhead dan de IR en raid functionaliteit heb je toch niet nodig.

[A1AD]

u_nix_we_all schreef op woensdag 10 februari 2016 @ 13:52:
[...]
OK, succes. Voor ZFS kun je het best de IT versie gebruiken, minder overhead dan de IR en raid functionaliteit heb je toch niet nodig.

Ok, thanks de IT mode staat er ondertussen al op

[F-Tim]

Ik zit een beetje te puzzelen met de Samba shares op mijn ZFSguru installatie, maar ik krijg het niet geheel werkend hoe ik het wil...

Er zijn 3 shares aangemaakt, 2 "private" shares, waarbij alleen de groep "Thuis" rechten heeft, en 1 public share, waar Everyone (incl. Guest user) volledige rechten heeft.

Vanuit Windows kan ik op meerdere devices alle shares gewoon benaderen. Bij de private shares kan ik gewoon inloggen met een gebruiker uit de groep Thuis.

Vanuit iOS zie ik bv in de nPlayer app wél de 3 shares, maar zodra ik wil inloggen blijft hij zeuren over de gebruiker. Wil ik met de nPlayer app bv naar een willekeurige andere Windows share gaan, dan kan ik daar wél inloggen. De public share zonder inlog, werkt uiteraard wél gewoon, inclusief het up- en downloaden van bestanden.

Moet ik nog iets additioneels instellen alvorens ik het bv op de iPad/iPhone wel goed kan gebruiken? Ik had ook nog geprobeerd om een NFS share aan te maken, maar die kan ik al helemaal niet koppelen op iOS

[maomanna]

Hoe verstandig is het om een ZFS pool na bijv 10minuten geen lees/schrijfactiviteit te downspinnen?

Gezien ik ong 12 disks heb, is het verbruik nogal aardig, dus om dat te minderen heb ik er opzich wel oren naar. Maar als disks dan niet goed terug mounten oid is het een ander verhaal.

Hoe is jullie ervaring ermee?

[Verwijderd]

Ik heb er slechte ervaringen mee, omdat bij het opspinnen de disks sequentiëel worden aangesproken en niet allemaal tegelijk. Wil je dus weer even wat van je pool lezen, duurt dat gelijk een minuut ofzo. Dat is niet meer fijn werken.

In plaats daarvan gebruik ik een RAID0 pool met twee keer WD Green 6TB. Prima snel en 12TB is voor mijn alledaagse dingen genoeg. De grote servers hoeven dan alleen aan als ik de data erop nodig heb, wat niet zo heel vaak is. En voor nightly sync maar dat gaat automatisch. Het opstarten van de grote server duurt ook iets van een minuut, dus echt veel verschil is er niet qua tijd.

[maomanna]

dat het een minuut duurt is niet zo erg. als ze daarvoor bij wijze van 23 uur uit staan, is daar een beste winst te halen.

Hoef alleen de scans van Sonarr(Sickbeard) en couchpotato te vertragen naar 1x in 24uur.

Ik weet niet of het mogelijk is om een tijdspanne op te geven, zoals bijv: ma, di, do en vrijdag disks offline van 1:00 tot 17:45 en de andere dagen altijd aan? Dan kan ik toch snel bij de data als ik thuis ben en als ik er niet ben, ze uitstaan.

Bovendien heb ik 3 pools, de grootste met films en series kan ik natuurlijk wel uitzetten indien nodig.
De belangrijke data gewoon door laten lopen.

[ Voor 14% gewijzigd door maomanna op 16-02-2016 13:23 ]

[CurlyMo]

Je kan natuurlijk in een cron om bepaalde tijden de APM/AAM waarden in je schijven omzetten. Dus naar "Maximum Performance" overdag en naar "Minimum power consumption with Standby" 's avonds.

[riwi]

Ik heb de spindown tijd op een uur gezet bij mij. 3 pools van 10 disks en 1 pool van 13 disks.
Dus als ik iets opvraag van een pool die down gespinned is duurt het wel 10 x 5 seconden ongeveer.
Voordeel is dat als ik een film kijk er 3 pools in slaap vallen, dus kwa stroom verbruik beter.
10 minuten zou ik te kort/irritant vinden.

's nachts zet ik ze gewoon uit die machines. En voor always on data heb ik een ander servertje dat maar 10Watt doet en 700GB data heeft op SSD.

[narotic]

maomanna schreef op dinsdag 16 februari 2016 @ 13:23:
Bovendien heb ik 3 pools, de grootste met films en series kan ik natuurlijk wel uitzetten indien nodig.
De belangrijke data gewoon door laten lopen.

Zo heb ik 't hier ook opgelost: root pool op 2.5" schijven staat altijd aan, data pool met films etc. op 3.5" schijven gaat na 30 minuten op idle. Ikzelf kan met de delay van 't opspinnen wel leven, maar bij sommige programma's veroorzaakt het wel een timeout af en toe.

Let verder ook op dat FreeBSD zijn daily/weekly/monthly cronjobs ook in de nacht draait, waaronder ook de update van de locate database. Verder worden APM/AAM instellingen niet permanent opgeslagen (correct me if I am wrong), dus je moet ze na elke boot opnieuw laten instellen.

[FireDrunk]

Ik krijg binnenkort een paar QLogic Fibre Channel kaartjes. Ik had het idee om voor de grap eens te proberen om een ZFS Send & Receive voor elkaar te krijgen via een ZVOL.

Dus:
- Snapshot regulier volume
- Mount ZVOL
- Send snapshot naar file op ZVOL
- unmount ZVOL
- Exporter ZVOL over Fibre
- Mount ZVOL op andere machine
- ZFS Receive de file naar je destination.

Iemand die hier heil in ziet? Het is gewoon voor de lol om er eens mee te spelen, het is niet dat ik honderden Terrabytes over wil pompen.

Ik zit zelfs te denken, ik kan ook de pool exporteren, en alle individuele devices via Fibre Channel exporteren en de pool reassembelen op de ontvangende host

[ Voor 13% gewijzigd door FireDrunk op 17-02-2016 09:09 ]

[CurlyMo]

Waarom deze stap:

- Send snapshot naar file op ZVOL

En niet?

- Send snapshot naar ZVOL

[Verwijderd]

Een snapshot kan toch niet direct naar een block device worden gestuurd, of wel?

[FireDrunk]

Daar zit dus een filesystem tussen (kan ook weer ZFS zijn.)

net geprobeerd:

zfs send VM_TIER_2/vagrant@full > /dev/zvol/VM_TIER_2/test_zvol

Dat krakt heel hard...

[ Voor 51% gewijzigd door FireDrunk op 17-02-2016 11:01 ]

[HyperBart]

maomanna schreef op dinsdag 16 februari 2016 @ 13:23:
dat het een minuut duurt is niet zo erg. als ze daarvoor bij wijze van 23 uur uit staan, is daar een beste winst te halen.

Hoef alleen de scans van Sonarr(Sickbeard) en couchpotato te vertragen naar 1x in 24uur.

Hoeft natuurlijk niet per se, je kan ook een SSD toevoegen als L2ARC en voor de filesystems waar je series en films op staan de property van L2 Cache instellen op metadata only. Zo staat het hier geconfigureerd, als je de HTPC aanzet kan je vrolijk en vrij overal doorscrollen zonder dat er iets opspint, ook lekker snel want de hele directory structuur komt van SSD.

Ik weet niet of het mogelijk is om een tijdspanne op te geven, zoals bijv: ma, di, do en vrijdag disks offline van 1:00 tot 17:45 en de andere dagen altijd aan? Dan kan ik toch snel bij de data als ik thuis ben en als ik er niet ben, ze uitstaan.

Bovendien heb ik 3 pools, de grootste met films en series kan ik natuurlijk wel uitzetten indien nodig.
De belangrijke data gewoon door laten lopen.

[CurlyMo]

FireDrunk schreef op woensdag 17 februari 2016 @ 10:38:
Daar zit dus een filesystem tussen (kan ook weer ZFS zijn.)

net geprobeerd:

zfs send VM_TIER_2/vagrant@full > /dev/zvol/VM_TIER_2/test_zvol

Dat krakt heel hard...

Opnieuw, waarom niet:

zfs send VM_TIER_2/vagrant@full  | zfs recv /dev/zvol/VM_TIER_2/test_zvol@full

[FireDrunk]

Huh, hij kan toch geen filesystem maken op een ZVOL? Dat is toch geen ZFS pool...?

[root@NAS ~]# zfs send VM_TIER_2/vagrant@full | zfs recv /dev/zvol/VM_TIER_2/test_zvol@full
cannot receive: invalid name
warning: cannot send 'VM_TIER_2/vagrant@full': Broken pipe

[ Voor 55% gewijzigd door FireDrunk op 17-02-2016 11:25 ]

[CurlyMo]

Geef me even

~ # dd if=/dev/zero of=output.dat  bs=1G count=1
~ # dd if=/dev/zero of=output1.dat  bs=1G count=1
~ # zpool create test mirror ~/output.dat ~/output1.dat
~ # zfs create -V 500M test/zvol
~ # dd if=/dev/random of=/test/test.dat  bs=1M count=1
~ # zfs snapshot test@snap
~ # zfs send test@snap | zfs receive -F test/zvol@snap
~ # zfs set mountpoint=/mnt
~ # zfs mount -a
~ # ls /mnt/test/
test.dat
~ # zfs list -t snapshot -r test
NAME             USED  AVAIL  REFER  MOUNTPOINT
test@snap           0      -  19.5K  -
test/zvol@snap     1K      -  19.5K  -
~ # md5sum /test/test.dat
c2bf55dc254d7398706bab8c4db7018c  /test/test.dat
~ # md5sum /mnt/test.dat
c2bf55dc254d7398706bab8c4db7018c  /mnt/test.dat
~ # rm /test/test.dat
~ # zfs destroy test@snap
~ # zfs send test/zvol@snap | zfs receive -F test@snap
~ # md5sum /test/test.dat
c2bf55dc254d7398706bab8c4db7018c  /test/test.dat

Werkt prima

[ Voor 96% gewijzigd door CurlyMo op 17-02-2016 11:46 ]

[maomanna]

HyperBart schreef op woensdag 17 februari 2016 @ 10:52:
[...]

Hoeft natuurlijk niet per se, je kan ook een SSD toevoegen als L2ARC en voor de filesystems waar je series en films op staan de property van L2 Cache instellen op metadata only. Zo staat het hier geconfigureerd, als je de HTPC aanzet kan je vrolijk en vrij overal doorscrollen zonder dat er iets opspint, ook lekker snel want de hele directory structuur komt van SSD.

[...]

mmm dat klinkt ook goed idd.
L2ARC heb ik al in mn pool. Eens zoeken hoe ik die metadata only ingesteld krijg.

[FireDrunk]

CurlyMo schreef op woensdag 17 februari 2016 @ 11:27:
Geef me even

~ # dd if=/dev/zero of=output.dat  bs=1G count=1
~ # dd if=/dev/zero of=output1.dat  bs=1G count=1
~ # zpool create test mirror ~/output.dat ~/output1.dat
~ # zfs create -V 500M test/zvol
~ # dd if=/dev/random of=/test/test.dat  bs=1M count=1
~ # zfs snapshot test@snap
~ # zfs send test@snap | zfs receive -F test/zvol@snap
~ # zfs set mountpoint=/mnt
~ # zfs mount -a
~ # ls /mnt/test/
test.dat
~ # zfs list -t snapshot -r test
NAME             USED  AVAIL  REFER  MOUNTPOINT
test@snap           0      -  19.5K  -
test/zvol@snap     1K      -  19.5K  -
~ # md5sum /test/test.dat
c2bf55dc254d7398706bab8c4db7018c  /test/test.dat
~ # md5sum /mnt/test.dat
c2bf55dc254d7398706bab8c4db7018c  /mnt/test.dat
~ # rm /test/test.dat
~ # zfs destroy test@snap
~ # zfs send test/zvol@snap | zfs receive -F test@snap
~ # md5sum /test/test.dat
c2bf55dc254d7398706bab8c4db7018c  /test/test.dat

Werkt prima

Dit werkt alleen maar omdat je zfs receive gebruikt in combinatie met het feit dat je lokale machine de ZVOL kent. Stel je nu eens voor dat ik een snapshot op een USB block device wil zetten zonder dat er al ZFS op de USB stick staat.

Dus eigenlijk: zfs send pool/fs@snapshot | /dev/sdc

[CurlyMo]

FireDrunk schreef op woensdag 17 februari 2016 @ 13:29:
Dus eigenlijk: zfs send pool/fs@snapshot | /dev/sdc

Dat werkt inderdaad niet. Maar jij hebt het over een zvol niet over een standaard blockdevice.

[FireDrunk]

Wat is het verschil (in dit geval)? Ik snap uiteraard het technische verschil, maar ik wil juist het ZVOL naderhand exporteren naar een ander systeem.

Zodra ik dat ZVOL exporteer kan ik niet met de ZFS installatie van de andere machine dat ZVOL weer inlezen als zijnde een ZVOL. Het is dan 'gewoon' een blockdevice.

Op het 'ontvangende' systeem krijg je dus:

cat /dev/mapper/lun0 | zfs recv -F ontvangendepool/fs@snapshot

[CurlyMo]

Dan heb toch gewoon een piped send / receive:

zfs send ... | ... | zfs recv ...

Of dat nu tussen machines is of lokaal.

Ik snap niet zo goed wat die zvol dan in het verhaal doet.

[FireDrunk]

Een ZVOL is iets wat ik kan exporteren over Fibre Channel. Een file niet.

[CurlyMo]

Maar je kan niet direct naar je Fibre Channel schrijven zoals je ook raw socket kan schrijven?

code:

echo "bla bla bla" > /dev/mapper/lun0

[FireDrunk]

Dat probeerde ik dus, maar daar krakte ZFS nogal hard op...

[CurlyMo]

Omdat je naar een zvol probeer te schrijven. Ik bedoel direct naar de "named pipe"?

[ Voor 13% gewijzigd door CurlyMo op 17-02-2016 14:17 ]

[FireDrunk]

Een ZVOL *is* een blockdevice? Ik heb nog niks gedaan met Fibre Channel (heb de kaarjtes nog niet).

Je kan sowieso gewoon dd if en dd of van en naar een ZVOL doen, dat heb ik al vaker gedaan.

[CurlyMo]

Aha, dus je gebruikt de zvol om een blockdevice te simuleren?

[FireDrunk]

Zo kun je het wel zien ja. Maar het blockdevice buiten ZFS om gebruiken als Snapshot target gaat dus niet.

[CurlyMo]

Dat is op zich een no-brainer toch?

[FireDrunk]

Nou ja, ik had stille hoop dat zfs send ook naar een block device kon schrijven. Beetje als een tape streamer. Maar nu moet ik dus een manier verzinnen om het block device beschrijfbaar te maken.

[narotic]

HyperBart schreef op woensdag 17 februari 2016 @ 10:52:
[...]

Hoeft natuurlijk niet per se, je kan ook een SSD toevoegen als L2ARC en voor de filesystems waar je series en films op staan de property van L2 Cache instellen op metadata only. Zo staat het hier geconfigureerd, als je de HTPC aanzet kan je vrolijk en vrij overal doorscrollen zonder dat er iets opspint, ook lekker snel want de hele directory structuur komt van SSD.

[...]

Maar werkt dat ook voor XBMC's library updates? Die openen ook de files om bestandstype, resolutie e.d. te bepalen, dus het lijkt me dat de schijven dan alsnog opspinnen.

[narotic]

FireDrunk schreef op woensdag 17 februari 2016 @ 13:29:
[...]


Dit werkt alleen maar omdat je zfs receive gebruikt in combinatie met het feit dat je lokale machine de ZVOL kent. Stel je nu eens voor dat ik een snapshot op een USB block device wil zetten zonder dat er al ZFS op de USB stick staat.

Dus eigenlijk: zfs send pool/fs@snapshot | /dev/sdc

Weet je zeker dat je fout niet is dat je een pipe gebruikt in plaats van redirection?

Zfs send naar USB block device:

root@t420:~# zfs send zroot/tmp@snap > /dev/sdc 
root@t420:~# head -c 96 /dev/sdc | hexdump -C
00000000  00 00 00 00 00 00 00 00  ac cb ba f5 02 00 00 00  |................|
00000010  11 00 00 00 00 00 00 00  9f bf c4 56 00 00 00 00  |...........V....|
00000020  02 00 00 00 00 00 00 00  46 b8 9a 69 85 22 62 43  |........F..i."bC|
00000030  00 00 00 00 00 00 00 00  7a 72 6f 6f 74 2f 74 6d  |........zroot/tm|
00000040  70 40 73 6e 61 70 00 00  00 00 00 00 00 00 00 00  |p@snap..........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Zfs send naar zvol block device:

root@t420:~# zpool create -f tmppool /dev/sdc
root@t420:~# zfs create -V 512M tmppool/block
root@t420:~# zfs send zroot/tmp@snap > /dev/zvol/tmppool/block
root@t420:~# head -c 96 /dev/zvol/tmppool/block | hexdump -C
00000000  00 00 00 00 00 00 00 00  ac cb ba f5 02 00 00 00  |................|
00000010  11 00 00 00 00 00 00 00  9f bf c4 56 00 00 00 00  |...........V....|
00000020  02 00 00 00 00 00 00 00  46 b8 9a 69 85 22 62 43  |........F..i."bC|
00000030  00 00 00 00 00 00 00 00  7a 72 6f 6f 74 2f 74 6d  |........zroot/tm|
00000040  70 40 73 6e 61 70 00 00  00 00 00 00 00 00 00 00  |p@snap..........|
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Is dit niet wat je wilt of zie ik iets over het hoofd?

[CurlyMo]

Ik zie ook niet waarom je niet naar een blockdevice kan schrijven. ZFS weet toch niet waar je naar schrijft? ZFS poept gewoon bepaalde data uit. Waar je dat opslaat boeit niet. Alleen weet alleen ZFS receive wat je met die data kan doen.

-------

Dit kan allemaal:

code:

zfs send rpool/zfsguru/services/10.1-001@GMT-2016.02.17-00.00.00 | cat
zfs send rpool/zfsguru/services/10.1-001@GMT-2016.02.17-00.00.00 | hexdump -C
zfs send rpool/zfsguru/services/10.1-001@GMT-2016.02.17-00.00.00 > test
zfs send rpool/zfsguru/services/10.1-001@GMT-2016.02.17-00.00.00 > /dev/sda

enz.

Die Hexdump is overigens wel leuk. Dan zie je de daadwerkelijke ZFS snapshot inhoud (met een hele hoop nullen).

[ Voor 49% gewijzigd door CurlyMo op 17-02-2016 20:03 ]

[FireDrunk]

Nou, Hierom:

[root@NAS ~]# zpool list VM_TIER_2
NAME        SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
VM_TIER_2   476G   171G   305G         -    71%    35%  1.00x  ONLINE  -
[root@NAS ~]# zfs list -t snapshot
NAME                     USED  AVAIL  REFER  MOUNTPOINT
VM_TIER_2/vagrant@full      0      -  8.59G  -

[root@NAS ~]# zfs send VM_TIER_2/vagrant@full | pv > /dev/zvol/VM_TIER_2/test_zvol
8.27GiB 0:00:18 [ 330MiB/s] [=======>                                                                                                       ]  8% ETA 0:03:19

Na precies 8.6G hangt het proces en stopt de progres... De pipe die geopend wordt is dus ergens stuk, en de redirection werkt niet goed...

EDIT: oh, ineens issie klaar... vage pv voortgangsindicator

[ Voor 14% gewijzigd door FireDrunk op 17-02-2016 20:51 ]

[CurlyMo]

Waar was dat een antwoord op ?

[FireDrunk]

Op je eerste waarom vraag. Maar het werkt dus, en de fibre kaartjes zijn er over 10 minuten, dus morgen maar eens proberen met mijn microserver

[secretdk]

Volgens mij was dit nog niet eerder gepost. ZFS native in 16.04

http://arstechnica.com/ga...ntu-16-04-lts-by-default/

[narotic]

Interessant en een behoorlijke klap in het gezicht van BTRFS. Wat me nou niet duidelijk is of dit betekent dat de installer ook ZFS on Root installaties ondersteunt of niet? Dat is met de huidige distro's vaak een behoorlijke PITA.

[Verwijderd]

Hopelijk betekent het in elk geval dat ZFS op Linux een boost krijgt, want de toegenomen exposure door een stap als deze zal waarschijnlijk betekenen dat de hoeveelheid bugfixes zal toenemen en daarmee de kwaliteit ten goede komen. Hopelijk kan zo het gat met BSD enigszins worden teruggebracht.

[FireDrunk]

Helaas wordt het gat tussen Linux en BSD op andere fronten weer groter gemaakt

(Lees: systemd)

[A1AD]

[message=45913411,noline]FireDrunk schreef op zaterdag 20 februari 2016 @ 11:51[/op message]:
(Lees: systemd)

Je hebt het er echt niet voor he. Care to elaborate?

[FireDrunk]

NOS Kroeg - Deel 2

Hier staat een hele discussie over systemd

[ Voor 16% gewijzigd door FireDrunk op 20-02-2016 14:43 ]