Identificeer disk op UUID, niet het volume

[Verwijderd]

Het valt mij op dat enkel partities een UUID krijgen. Althans... Ik kan geen UUIDs bij een disk vinden.
Ik ben bezig met een ZFS-experimentje onder Linux en ik wil de schijven, niet de partities dus, in een RAIDZ volume hangen.
Aangezien ik weleens wat schijven bij plaats loop ik het gevaar dat Linux doornummert. Dus /dev/sdh, kan zomaar /dev/sdi worden. Daarom zou het volume maken op UUID een mooie optie zijn.

Iemand een idee hoe ik dit wel voor de bakker krijg?

Van mij hoeft het natuurlijk niet per sé op UUID, ik zie dit enkel vooralsnog even als enige oplossing. Behalve dan dus dat me dit niet gelukt.

[soczol]

Je kunt kijken naar /dev/disk/by-uuid/:

code:

$ ls /dev/disk/by-uuid/ -l
total 0
lrwxrwxrwx 1 root root 10 Apr  7  2011 1ecce034-539a-48e3-94cc-c3e1d2f7204c -> ../../sda1
lrwxrwxrwx 1 root root 10 Apr  7  2011 43987226-a103-4044-a24e-a53fd09ac6f8 -> ../../sda5
lrwxrwxrwx 1 root root 10 Apr  7  2011 5d16068c-556a-4f25-81ae-9bea78ca3eaa -> ../../sdb1
lrwxrwxrwx 1 root root 10 Apr  7  2011 efc015b3-da90-43d3-86b0-113ce8f9f6e8 -> ../../sdc1

[Verwijderd]

Ja, dat is dus mijn punt. Zoals in jouw voorbeeld: Hij toont geen UUID bij /dev/sda, /dev/sdb of /dev/sdc. Enkel bij sda1, sda5, sdb1 en sdc1. De volumes dus.
Het had zo leuk geweest als ook de disk een UUID kreeg. Of misschien krijgt 'ie die wel, maar weet niet hoe ik dat zichtbaar kan krijgen.

[DataGhost]

Je zou met udev-rules persistent devices/links kunnen maken adhv serienummer bijvoorbeeld. Ik heb bijv. zoiets:

code:

ENV{DEVTYPE}=="disk", PROGRAM="/root/sdfix.sh $env{ID_PATH}", SYMLINK+="%c"

Volgens die structuur zou je wat leuks met een serienummer ofzo kunnen doen. Ik kon het serienummer volgens mij niet direct uit udev krijgen dus in dat scriptje kan je misschien met hdparm iets uitlezen. Wat ik zelf heb gedaan is adhv de verbinding met de controller (bijv. pci-0000:04:00.0-scsi-1:0:0:0) een mapping gemaakt, misschien is dat al genoeg voor je.

Edit: ik kan me trouwens niet echt voorstellen dat dit zomaar misgaat, mdadm-raid autodetect het ook gewoon als je schijven van benaming veranderd zijn, aangezien die scant naar 0xfd-partities en dan in het superblock kijkt naar het uuid van de raidset. Doet ZFS/RAIDZ dat niet ook gewoon? Het lijkt me stug dat je de eerste bent die hier anders een probleem mee zou hebben

[ Voor 25% gewijzigd door DataGhost op 11-02-2013 20:09 ]

[AlterEgo]

Kun je niet /dev/disk/by-id gebruiken in plaats van /dev/disk/by-uuid ?

Voorbeeld:

code:

ls /dev/disk/by-id/scsi-SATA_INTEL_SSD* -l 
lrwxrwxrwx 1 root root  9 Feb 11 18:55 /dev/disk/by-id/scsi-SATA_INTEL_SSDSA2M08CVPO005405EV080BGN -> ../../sda
lrwxrwxrwx 1 root root 10 Feb 11 18:55 /dev/disk/by-id/scsi-SATA_INTEL_SSDSA2M08CVPO005405EV080BGN-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 Feb 11 18:55 /dev/disk/by-id/scsi-SATA_INTEL_SSDSA2M08CVPO005405EV080BGN-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 Feb 11 18:55 /dev/disk/by-id/scsi-SATA_INTEL_SSDSA2M08CVPO005405EV080BGN-part3 -> ../../sda3

[ Voor 79% gewijzigd door AlterEgo op 11-02-2013 20:15 ]

[Verwijderd]

@AlterEgo:
Da's heel raar, daar staat alleen mijn CD-ROM drive in.

[Verwijderd]

@DataGhost:
Ik weet niet of mdadmin-autodetect dit dafault doet, maar in ieder geval doet ZFS dit standaard niet. Getest!
10 schijven in een machine. /dev/sda tm /dev/sdj. RAID-Z volume stond op /dev/sdf tm /dev/sdj.
Machine uit,
Ik haal de disks die /dev/sdb tm /dev/sde waren eruit, opnieuw opstarten: ZPOOL vernaggeld. Werkelijke status-indicatie moet ik je schuldig blijven.

[Hero of Time]

Je zal toch een partitie oid moeten hebben op de schijf voordat je er iets mee kan. Dus dan kan je ze ook identificeren. Maar disk/by-path is het makkelijkste. Btw, waarom geen dm-raid array maken of LVM? Schijven krijgen dan meta-data om ze te identificeren.

[Verwijderd]

@Hero Of Time:
"Je zal toch een partitie oid moeten hebben op de schijf voordat je er iets mee kan"
Met ZFS dus niet.
Sterker, dat stond er ook eigenlijk al. Ik had immers al een pool werkend.

/dev/disk/by-path
Is een aardige optie. Alleen is het mij nog niet flexibel genoeg. Het zou mooi zijn als de disk de identifier bij zich draagt, en dus niet verzorgd door andere hardware.
En zoals DataGhost ook stelt: Het kan toch niet al te ingewikkeld zijn...

"Waarom geen dm-raid array maken of LVM?"
Uhm, omdat ik aan het experimenteren ben met ZFS misschien?
Of wil je nu een fundamentele discussie starten ZFS vs Linux LVM?

[Verwijderd]

Ah, hier heb ik de screenshots van een zpool 'begonnen met sdc'.
Eerst werkend.
http://www.krusj.nl/zpoolwerken.png


En toen de schijf die /dev/sdb was verwijderd. Toen opnieuw opgestart.
Vond 'ie niet superleuk...
http://www.krusj.nl/zpoolkaduuk.png

[Hero of Time]

Een discussie starten voor ZFS vs LVM? Dat zou ik grandioos verliezen. Waarom? Geen enkele ervaring met ZFS en te weinig met LVM. Het waren maar suggesties om je schijven te identificeren.

[Verwijderd]

Hero Of Time schreef op maandag 11 februari 2013 @ 23:16:
Een discussie starten voor ZFS vs LVM? Dat zou ik grandioos verliezen. Waarom? Geen enkele ervaring met ZFS en te weinig met LVM. Het waren maar suggesties om je schijven te identificeren.

Sportief. Sorry voor mijn wat geagiteerde reactie.

[blaataaps]

Verwijderd schreef op maandag 11 februari 2013 @ 23:05:
@Hero Of Time:
"Je zal toch een partitie oid moeten hebben op de schijf voordat je er iets mee kan"
Met ZFS dus niet.

Met LVM, mdadm, ext{3,4}, xfs enzovoorts hoeft dat ook niet

[CyBeR]

Is de simpelste oplossing niet gewoon alsnog een partitie maken op je schijven, die de hele schijf beslaat, en díe dan toevoegen aan je zpool?

Punt is, als je geen partitie hebt, dan heeft je disk ook geen metadata. De UUID wordt er gewoon op weggeschreven namelijk maar daar is nu geen plek voor.

[ Voor 35% gewijzigd door CyBeR op 12-02-2013 10:59 ]

[Verwijderd]

Okay, dat is een simpele verklaring. Dankjewel.
Punt met ZFS is dat 'ie zelf de partitie-aanmaak afhandelt.

code:

# parted /dev/sde print
Disk /dev/sde: 2190GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2190GB  2190GB               zfs
 9      2190GB  2190GB  8389kB

Ik heb zomaar het vermoeden dat het gewoon gaat werken: Dat ZFS dat volume gewoon behandeld als disk, en daarin dat partities aan gaat maken...

[CyBeR]

Verwijderd schreef op dinsdag 12 februari 2013 @ 12:36:
Okay, dat is een simpele verklaring. Dankjewel.
Punt met ZFS is dat 'ie zelf de partitie-aanmaak afhandelt.

code:

# parted /dev/sde print
Disk /dev/sde: 2190GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  2190GB  2190GB               zfs
 9      2190GB  2190GB  8389kB

Ik heb zomaar het vermoeden dat het gewoon gaat werken: Dat ZFS dat volume gewoon behandeld als disk, en daarin dat partities aan gaat maken...

Ah, daar staat dat er een gpt table op staat. Daarin zouden uuids moeten zitten. (Dat is het hele punt van gpt tenslotte.)

[Verwijderd]

Ja, maar dat is dan toch per definitie op de volumes?

[Hero of Time]

UUIDs heb je op partities en is ongeacht de partitieindeling. MBR of GPT maakt dan niet uit. Maar wat ik van CyBeR begrijp, is dat GPT als indeling an sich, ongeacht of er een partitie is of niet, ook via een UUID is te identificeren.

[CyBeR]

Als 't goed is wel; de vraag is echter of Linux dat ontsluit. Ik kan 't tot dusverre ook niet vinden moet ik zeggen.

[ Voor 31% gewijzigd door CyBeR op 12-02-2013 14:07 ]

[Verwijderd]

haha, jammer. Ja, anders hadden we dat toch al ergens moeten aantreffen denk ik.
Eigenlijk dus in eerste instantie de aanleiding van mijn posting.

Overigens heb ik tot diep in de nacht me in zitten lezen in ZFS (Oracle, vroeger Sun) ZFSonLinux en heb er dus nog niets over kunnen vinden.
En dan doel ik in dit geval op auto-detect of de term pool-discovery, een term in de zfs-hoek wordt gebruikt, maar die lijken toch op iets anders te duiden. In ieder geval kom ik bij iets anders uit.

Punt is trouwens ook dat als ik op Linux en UUID en disk zoek ik altijd maar die eeuwige volumes zie. Kennelijk wordt dat overal nogal door elkaar gebruikt als het UUIDs betreft.

[AlterEgo]

Verwijderd schreef op maandag 11 februari 2013 @ 21:55:
@AlterEgo:
Da's heel raar, daar staat alleen mijn CD-ROM drive in.

Doe eens een udevtrigger?

[LauPro]

Zit er support voor die gpt in jouw kernel?

[Verwijderd]

Ik wil niet pietluttig doen, maar wat bedoel je specifiek met 'die gpt'?
Zijn daar verschillende versies van of iets?

[Verwijderd]

Doe eens een udevtrigger?

udev trigger levert geen 'nieuwe devices' op.

udevadmin monitor nog aangezet en /etc/init.d/udev restart gedaan.
Teksten schieten voorbij... alles schijven worden gezien als scsi-disk. Niets mis mee lijk mij...
Maar onder iets als /dev geen nieuwe entries
Ook niet onder /etc/udev/rules

[HollowGamer]

blkid?

[Hero of Time]

HollowGamer schreef op dinsdag 12 februari 2013 @ 18:24:
blkid?

Doet alleen partities met bekend file system. Als zfspool zelf partities maakt, zal je die zien, maar in hoeverre dat betrouwbaar is... Overigens staat in z'n screenshots de device node van de schijf zelf voor z'n pool, in een zelfde idee hoe mdadm z'n array opzet.

[Verwijderd]

ZFSonLinux documentatie is er vrij helder over. In die zin: Over UUIDs wordt niet gerept.
Wat zij zeggen is /dev/disk/by-id, maar zoals ik al eerder schreef: Die blijft leeg bij mij. Ook met een andere distro. Draaide Gentoo64, getest Ubuntu64, allebei leeg.
Andere hardware met CentOS, andere hardware met ClearOS, allebei entries in /dev/disk/by-id.
Dat zijn echter operationele machines die ik niet zomaar even kan rebooten. Wordt dus voor later...

Verders...
Die blkid is lang nog niet zo'n slechte optie!
Geheel tegen mijn verwachting 'zet' ZFS wel labels

code:

gentoo64 / # blkid 
/dev/sda1: LABEL="boot" UUID="afa799b3-ec41-41ff-b372-fe51b90243b5" TYPE="ext4" 
/dev/sda2: LABEL="swap" UUID="fc161a6a-4487-4d0b-9b22-5811c7df5a4d" TYPE="swap" 
/dev/sda3: LABEL="root" UUID="b967b152-2a91-41a5-a5f9-c6e397489451" TYPE="ext4" 
/dev/sdb1: LABEL="data" UUID="5988085009493855674" UUID_SUB="13422401735652284642" TYPE="zfs_member" 
/dev/sdc1: LABEL="data" UUID="5988085009493855674" UUID_SUB="7691258612419950516" TYPE="zfs_member" 
/dev/sdd1: LABEL="data" UUID="5988085009493855674" UUID_SUB="17918633689030586377" TYPE="zfs_member" 
/dev/sde1: LABEL="data" UUID="5988085009493855674" UUID_SUB="1074415512938172209" TYPE="zfs_member"

Jammer echter dat ik er geen volgorde uit kan destileren.
Voorts neemt 'ie /dev/sdf niet mee. Jammer, want dat is namelijk mijn cache-disk.

Je/Ik zou dan gemakkelijk een scriptje kunnen schrijven dat de hele boel weer in elkaar beukt, als een autodetect optie. Daar zou de wereld toch een stukje beter van worden...


Situatie heden:

code:

gentoo64 / # zpool status
  pool: data
 state: ONLINE
  scan: none requested
config:

    NAME        STATE     READ WRITE CKSUM
    data        ONLINE       0     0     0
      raidz1-0  ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0
    cache
      sdf       ONLINE       0     0     0

errors: No known data errors

NB: De ZFS documentatie lijkt ook heel stellig over disks vs partities.
In zoverre: Er wordt enkel 'gesproken' over disks. Zowel in uitleg als in voorbeelden. Ik geloof dus dat het verstandig is daar maar niet van af te wijken vooralsnog.

Ik begin er eigenlijk al meer lol in te krijgen! :-)