13.0 - where is /dev/diskid?

R

robot468

Code: 
#sysctl kern.geom.label.disk_ident.enable
kern.geom.label.disk_ident.enable: 1

#ls /dev/diskid
ls: /dev/diskid: No such file or directory

I didn't change the value of kern.geom.label.disk_ident.enable. It was on by default.
 
whats the output of
geom disk list
gpart list
mount

Following is my understanding, based on reading and mucking around on my systems, so it may not be "strictly
correct", but it should be "roughly correct or close enough for government work"

geoms "wither"

In the beginning of system boot, you will find a disk/geom referenced in a number of different ways (because geoms
are "tasted" during discovery):

/dev/ada0p1, /dev/gpt/"gptlabel", /dev/diskid/"somethingtoidentifythedisk", I think there are a few more ways (mostly based on labels, maybe ufs labelling).

All of these are visible, until the "first exclusive reference" (typically a mount command). This first exclusive reference makes all the other ones disappear; that's called "withering".

Rough example

You have a device, say ada0 that you used gpart to create 3 partitions on and you gpart labelled the freebsd-ufs one as "MyRoot", that partition has some uuid. During boot the system sees it as:
/dev/ada0p1
/dev/gpt/MyRoot
/dev/diskid/someuuid

If you have a line in your fstab to mount it:
/dev/ada0p1 / ufs defaults 0 0

then the /dev/gptMyRoot and /dev/diskid/someuuid go away after it is mounted.
If the line is
/dev/gpt/MyRoot / ufs defaults 0 0
then /dev/ada0p1 and /dev/diskid/somuuid go away

Same logic for /dev/diskid/someuuid.

The higher level directories /dev/gpt, /dev/diskid go away if there is nothing below them.
Referring to things using the labels is handy (best practice) because if you rebuild a system you could swap cables
around now your /dev/ada0 is on /dev/ada3, but if the label is used for mounting it all just works.
 
Hi!

mer said:
whats the output of
geom disk list
gpart list
mount
Click to expand...

Disk that i want to see in diskid/
Code: 
Geom name: da8
Providers:
1. Name: da8
   Mediasize: 256060514304 (238G)
   Sectorsize: 512
   Mode: r4w4e11
   descr: ATA TS256GSSD230S
   lunid: 57c35481e5c06b14
   ident: H149560084
   rotationrate: 0
   fwsectors: 63
   fwheads: 255
 
   Geom name: da8
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 500118151
first: 40
entries: 128
scheme: GPT
Providers:
1. Name: da8p1
   Mediasize: 524288 (512K)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 20480
   Mode: r0w0e0
   efimedia: HD(1,GPT,fe898028-0911-11ed-bc17-ecf4bbbef78c,0x28,0x400)
   rawuuid: fe898028-0911-11ed-bc17-ecf4bbbef78c
   rawtype: 83bd6b9d-7f41-11dc-be0b-001560b84f0f
   label: (null)
   length: 524288
   offset: 20480
   type: freebsd-boot
   index: 1
   end: 1063
   start: 40
2. Name: da8p2
   Mediasize: 68719476736 (64G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 544768
   Mode: r1w1e2
   efimedia: HD(2,GPT,11ceca61-0912-11ed-bc17-ecf4bbbef78c,0x428,0x8000000)
   rawuuid: 11ceca61-0912-11ed-bc17-ecf4bbbef78c
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: zboot0
   length: 68719476736
   offset: 544768
   type: freebsd-zfs
   index: 2
   end: 134218791
   start: 1064
3. Name: da8p3
   Mediasize: 17179869184 (16G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 68720021504
   Mode: r1w1e1
   efimedia: HD(3,GPT,11e71c5a-0912-11ed-bc17-ecf4bbbef78c,0x8000428,0x2000000)
   rawuuid: 11e71c5a-0912-11ed-bc17-ecf4bbbef78c
   rawtype: 516e7cb5-6ecf-11d6-8ff8-00022d09712b
   label: ssd_swap0
   length: 17179869184
   offset: 68720021504
   type: freebsd-swap
   index: 3
   end: 167773223
   start: 134218792
4. Name: da8p4
   Mediasize: 1073741824 (1.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 85899890688
   Mode: r1w1e2
   efimedia: HD(4,GPT,12001800-0912-11ed-bc17-ecf4bbbef78c,0xa000428,0x200000)
   rawuuid: 12001800-0912-11ed-bc17-ecf4bbbef78c
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: ssd_zil0
   length: 1073741824
   offset: 85899890688
   type: freebsd-zfs
   index: 4
   end: 169870375
   start: 167773224
5. Name: da8p5
   Mediasize: 169086861312 (157G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 86973632512
   Mode: r1w1e2
   efimedia: HD(5,GPT,121e27c9-0912-11ed-bc17-ecf4bbbef78c,0xa200428,0x13af2e60)
   rawuuid: 121e27c9-0912-11ed-bc17-ecf4bbbef78c
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: ssd_cache0
   length: 169086861312
   offset: 86973632512
   type: freebsd-zfs
   index: 5
   end: 500118151
   start: 169870376
Consumers:
1. Name: da8
   Mediasize: 256060514304 (238G)
   Sectorsize: 512
   Mode: r4w4e11

mer said:
All of these are visible, until the "first exclusive reference" (typically a mount command). This first exclusive reference makes all the other ones disappear; that's called "withering".
Click to expand...

All of my drives have gpt labeled partitions, that used by zfs pools by gpt labels. But they haven't disappeared from /dev/daXpY. For example:

Code: 
2. Name: da8p2
   Mediasize: 68719476736 (64G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 544768
   Mode: r1w1e2
   efimedia: HD(2,GPT,11ceca61-0912-11ed-bc17-ecf4bbbef78c,0x428,0x8000000)
   rawuuid: 11ceca61-0912-11ed-bc17-ecf4bbbef78c
   rawtype: 516e7cba-6ecf-11d6-8ff8-00022d09712b
   label: zboot0
   length: 68719476736
   offset: 544768
   type: freebsd-zfs
   index: 2
   end: 134218791
   start: 1064
 
 pool: zboot
 state: ONLINE
config:

        NAME            STATE     READ WRITE CKSUM
        zboot           ONLINE       0     0     0
          mirror-0      ONLINE       0     0     0
            gpt/zboot0  ONLINE       0     0     0
            gpt/zboot1  ONLINE       0     0     0

#ls /dev/da8p2
crw-r-----  1 root  operator   0x96 Aug 26 19:28 /dev/da8p2


UPD: The problem I'm trying to solve is smart monitoring by some uniq disk id.
 
Perhaps the raw devices don't wither, but it's "all the other ones".
Smart monitoring: not sure what the answer is to your problem. By default I think smartd defaults to all devices it finds.

ETA:
I think you may want to look at the glabel class, that seems to be the one that creates the /dev/diskid stuff.
man glabel may give you a clue
 
mer said:
I think you may want to look at the glabel class, that seems to be the one that creates the /dev/diskid stuff.
man glabel may give you a clue
Click to expand...
Glabel uses last sector of disk, already used by gpt metadata. We discussed this with you in another thread, if I remember correctly :)
 
  • Like
Reactions: mer
mer said:
Then I guess you're stuck with /dev/ada type of names for monitoring.
Click to expand...
No, plan "b" is to get the "geom disk list" in the script, search for the desired devices by id and get their daX names. But I thought the operating system would give me a more convenient solution. :)
 
  • Like
Reactions: mer
You must log in or register to reply here.
Back
Top