ZFS FreeBSD 13.0 disk identification

monaco87

monaco87

Hi, I'm coming from a Solaris background so have a few queries on FreeBSD 13.0 / OpenZFS, any help appreciated.

1. In Solaris 11- disks on SAS2 connections, even if they are SATA, are identified as /dev/dsk/<World Wide Number> and ZFS pools are created using these devices. This made it really easy to identify disks and ensured that disk id's did not change if disks moved between slots. I'm using FreeBSD 13.0 with an LSI SAS9201-16e and the drives show as da0, da1 etc. Is there any way to use an alternative naming scheme such as WWN or serial number. I've seen a few posts mentioning /dev/diskid devices but that directory does not seem to exist on FreeBSD 13.0.

2. If devices such as /dev/da0 are all that is available, is there any way to get the WWN associated with /dev/da0?

3. On OpenZFS is it recommended to give ZFS "the whole raw disk" when creating pools, e.g. use /dev/da0 rather than create a partition and use that? I know on Solaris "whole disk" was strongly encouraged.

Thanks, and if any of these questions are addressed elsewhere, apologies I did search before posting.
 
If I recall correctly, it's normal to find these two lines in loader.conf(5):

Code: 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"

Partly related discussion: <https://forums.freebsd.org/posts/550463>

monaco87 said:
… On OpenZFS is it recommended to give ZFS "the whole raw disk" …
Click to expand...

For ZFS (not necessarily OpenZFS) in FreeBSD, it's often highly recommended to give a partition (not an entire device).
 
My opinions, others may differ.
Labelling:
A FreeBSD geom can be labelled in a few different ways, in fact there are about 3 or 4 done automatically. Then you have the concept of withering.
One of the labelling is done with the gpart tool, the others disk_ident and gptid I think are automatic based on other information pulled from the disk when it's detected (tasted).
A lot of folks recommend creating partitions for the ZFS bits, labelling them however you want and then using that label in the zpool commands.

This is something from a while ago, the reasoning to me is sound and what I've been doing.

ZFS: do not give it all your HDD

Sometimes, holding out is the best decision.
www.freebsddiary.org

If you are creating a boot device you wind up with some partitions anyway, a boot partition (either efi or freebsd-boot).
 
In addition to the above, some repetion.

At first glance I'd guess you intend to have a separate BOOT disks(mirrors) VDEV?

Using the raw disks won't let you define a swap partition; I don't know what your "swap-thoughts" are.
More importantly and practical aspect perhaps is when a disk goes down in a mirror or RAIDZx and you need to replace it with an exact match or bigger. You might run into the problem that your favourite disk supplier only delivers the "same size" of another type/brand which happens to be just a few MBytes smaller: that won't resilver.

Can you give the link to OpenZFS where they recommend raw disks? I couldn't find it, may have just missed that. I've haven't come across anything where raw disk are recommended for FreeBSD ZFS.

Partitioning also gives you the opportunity to use GPT labels of which the naming conventions are a lot more attractive than handling Disk Ident (diskid) labels of raw disks. The latter are based on the disk serial number; special characters get encoded. As mentioned earlier FreeBSD has a quite flexible GEOM based layered strorage structure. For more genral info have a look at the FreeBSD Handbook online or Absolutely FreeBSD 3rd ed; for a more deep dive into storage: Michael Lucas's Storage Essentials.

If you're going to be working with ZFS on FreeBSD I recommend that you have a look at the two ZFS books (FreeBSD Development: Books, Papers, Slides), if these aren't already familiar to you.

I think Solaris didn't have BOOT environments: Managing Boot Environments is a serious topic to be considering in relation with ZFS.
 
This subject has been around the block a few times.

For the tank, the advantages of having the disk serial number and the physical position of the drive encoded into the ZFS mappings are compelling. You can tell at a glance where each disk is, and avoid that fatal mistake of replacing the wrong disk after a failure. This broad approach is suggested in the FreeBSD Mastery books on ZFS mentioned by Erichans above.

My tank disks are in a vertical stack, and I encode the position like the floor level in a high rise (English system, starting at zero). I use gpart to create one maximal partition on the disk for use by ZFS, and tag it with a label consisting of the last 12 characters of the serial number, and the level in the stack, e.g. "ZC135AE5:L0":
Code: 
TAB=$(echo | tr '\n' '\t')
# Get last "count" (default 15) characters of a disk serial number.
GetDiskSerialNumber()   # device [count]
{
    dev=$1
    count=${2:-15}
    sn=$(camcontrol identify $dev | \
        grep "serial number" | \
        sed -e 's/serial number[ $TAB]*//')
    nsn=$(echo -n "$sn" | wc -c)
    nsn=$(echo $nsn)
    start=1
    [ $nsn -gt $count ] && start=$(($nsn-$count))
    echo "$sn" | cut -c $start-$nsn
}

DISK=/dev/da0
LEVEL=0
SN=$(GetDiskSerialNumber $DISK 12)
gpart destroy -F $DISK
gpart create -s gpt $DISK
gpart add -t freebsd-zfs -l ${SN}:L{$LEVEL} $DISK
The zroot is different. On physical systems, I use a mirror formed from SSDs with full power loss protection, preferably on different controllers and power cables. Their physical position is more difficult to encode, but more likely to be known, and they need to have multiple partitions. But I still want to be able to know the serial number of a broken disk, at a glance. So I encode the serial number and the partition number into each partition label. Here is a typical root layout:
Code: 
2 x 256GiB boot disks (mirror) with ZFS SLOG and L2ARC:

--: 40 sectors: MBR legacy boot and reserved sectors
p1: 512KiB: freebsd-boot: manually constructed duplicates
p2: 16GiB: gmirror: freebsd-swap
p3: 86GiB: zfs-mirror: freebsd-zfs (zroot)
p4: 12GiB: zfs-mirror: freebsd-zfs (SLOG)
p5: 64GiB: stripe: freebsd-zfs (2 x 64GiB L2ARC)
p6: 60GiB: unused: freebsd-ufs (2 x 60GiB UFS, empty, trimmed)
and the construction method:
Code: 
DEV0=/dev/ada0
DEV1=/dev/ada1

# Get the serial numbers
SN0=$(GetDiskSerialNumber $DEV0 12)
SN1=$(GetDiskSerialNumber $DEV1 12)

# create the partition table
gpart destroy -F ${DEV0}
gpart destroy -F ${DEV1}
gpart create -s GPT ${DEV0}
gpart create -s GPT ${DEV1}

# Create a single, bootable partition spanning the entire disk,
# thus allowing non-GPT-aware BIOSes to boot from the disk
gpart bootcode -b /boot/pmbr ${DEV0}
gpart bootcode -b /boot/pmbr ${DEV1}

# Create a 512 kB boot partition at offset 40 -- which is the size of the
# FAT_32 "reserved sectors" (32 or 34 blocks) rounded up to 4 kB boundary.
# This is the same layout used by the FreeBSD 13 intaller
# (p1 is a 512k freebsd-boot partition, at offset 40, with p2 starting at 1m).
gpart add -i 1 -b 40 -s 512k -l ${SN0}:p1 -t freebsd-boot ${DEV0}
gpart add -i 1 -b 40 -s 512k -l ${SN1}:p1 -t freebsd-boot ${DEV1}
gpart bootcode -p /boot/gptboot -i 1 ${DEV0}
gpart bootcode -p /boot/gptboot -i 1 ${DEV1}

# Allign all subsequent partitions on a 1 MiB boundary
gpart add -a 1m -i 2 -s 16g -l ${SN0}:p2 -t freebsd-swap ${DEV0}
gpart add -a 1m -i 2 -s 16g -l ${SN1}:p2 -t freebsd-swap ${DEV1}
gpart add -a 1m -i 3 -s 86g -l ${SN0}:p3 -t freebsd-zfs ${DEV0}
gpart add -a 1m -i 3 -s 86g -l ${SN1}:p3 -t freebsd-zfs ${DEV1}
gpart add -a 1m -i 4 -s 12g -l ${SN0}:p4 -t freebsd-zfs ${DEV0}
gpart add -a 1m -i 4 -s 12g -l ${SN1}:p4 -t freebsd-zfs ${DEV1}
gpart add -a 1m -i 5 -s 64g -l ${SN0}:p5 -t freebsd-zfs ${DEV0}
gpart add -a 1m -i 5 -s 64g -l ${SN1}:p5 -t freebsd-zfs ${DEV1}
gpart add -a 1m -i 6 -l ${SN0}:p6 -t freebsd-ufs ${DEV0}
gpart add -a 1m -i 6 -l ${SN1}:p6 -t freebsd-ufs ${DEV1}

# Allocate the partitions, ready for the installer
# sudo kldload geom_mirror
# The swap entry in /etc/fstab should end up like this
# /dev/mirror/swap none swap sw         0 0
gmirror label -v -b round-robin swap /dev/gpt/${SN0}:p2
gmirror insert swap /dev/gpt/${SN1}:p2
# The root file system
zpool create zroot mirror /dev/gpt/${SN0}:p3 ${SN1}:p3
# SLOG for the tank.  Must be a mirror.  Must survive a power failure.
zpool add tank log mirror /dev/gpt/${SN0}:p4 /dev/gpt/${SN1}:p4
# L2ARC for the tank.  Volatile cache.  It's a stripe.
zpool add tank cache /dev/gpt/${SN0}:p5 /dev/gpt/${SN1}:p5
# Over-provisioning, UFS file system, trimmed, unused
newfs -E /dev/gpt/${SN0}:p6
newfs -E /dev/gpt/${SN0}:p6
 
Erichans said:
I think Solaris didn't have BOOT environments
Click to expand...
I think boot environments actually came from Solaris, specifically the beadm utility. BEs are basically "clones of snapshots" so the utilities (beadm, bectl) streamline/standardize the process.

I think the "whole disk on OpenZFS" was actually a question, at least that's the way I interpreted it. Basically "Solaris recommends whole disk/raw device, does that hold true for OpenZFS"
 
Erichans said:
Can you give the link to OpenZFS where they recommend raw disks? I couldn't find it, may have just missed that. I've haven't come across anything where raw disk are recommended for FreeBSD ZFS.
Click to expand...
Sorry I wasn't suggesting that OpenZFS recommended raw, more of a question as to whether the Solaris policy also applied for OpenZFS.
 
monaco87 said:
In Solaris 11- disks on SAS2 connections, even if they are SATA, are identified as /dev/dsk/<World Wide Number>
...
I've seen a few posts mentioning /dev/diskid devices but that directory does not seem to exist on FreeBSD 13.0.
Click to expand...
They should both exist: The same disk (and partition) will be visible both places. The directory /dev/diskid identifies disks by serial number though, not by WWN. I can't remember whether the is any mechanism to have disks (and partitions) by WWN.

It works on my home system, but I'm still on 12.X. To debug why it doesn't work, look at grahamperrin's advice, and start with "sysctl kern.geom.label".

This made it really easy to identify disks and ensured that disk id's did not change if disks moved between slots.
Click to expand...
For initially creating zpools, this is an excellent idea. Once the zpool is created, the volumes are usually found automatically, independent of where they are, so you don't need to worry about it.

If devices such as /dev/da0 are all that is available, is there any way to get the WWN associated with /dev/da0?
Click to expand...
With "camcontrol identify /dev/daX".

On OpenZFS is it recommended to give ZFS "the whole raw disk" when creating pools, e.g. use /dev/da0 rather than create a partition and use that? I know on Solaris "whole disk" was strongly encouraged.
Click to expand...
From a performance and correctness viewpoint, it makes no difference. My personal (very strong) preference is to use partitions. And to use gpart to give every partition a human-readable label. Those can be read with "gpart show -l".
 
monaco87 said:
… a Solaris background …
Click to expand...

I don't know whether there is (in/for Solaris) anything like lsblk(8) for Linux <https://man7.org/linux/man-pages/man8/lsblk.8.html>, but you might like sysutils/lsblk for FreeBSD.

I find output from lsblk easier to parse than output from gpart(8):

Code: 
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
ada0             0:119 932G GPT                                               - -
  ada0p1         0:121 260M efi                                    gpt/efiboot0 -
  <FREE>         -:-   1.0M -                                                 - -
  ada0p2         0:123  16G freebsd-swap                              gpt/swap0 SWAP
  ada0p2.eli     2:33   16G freebsd-swap                                      - SWAP
  ada0p3         0:125 915G freebsd-zfs                                gpt/zfs0 <ZFS>
  ada0p3.eli     0:132 915G -                                                 - -
  <FREE>         -:-   708K -                                                 - -
da0              0:148  15G GPT                                               - -
  <FREE>         -:-   1.0M -                                                 - -
  da0p1          0:149  15G freebsd-zfs                            gpt/duracell <ZFS>
da1              0:164  29G GPT                                               - -
  da1p1          0:171  29G freebsd-zfs                        gpt/cache-august <ZFS>
da3              2:56  466G GPT                                               - -
  <FREE>         -:-   1.0M -                                                 - -
  da3p1          2:57  466G freebsd-zfs                           gpt/Transcend <ZFS>

Code: 
=>        40  1953525088  ada0  GPT  (932G)
          40      532480     1  efiboot0  (260M)
      532520        2008        - free -  (1.0M)
      534528    33554432     2  swap0  (16G)
    34088960  1919434752     3  zfs0  (915G)
  1953523712        1416        - free -  (708K)

=>      34  32358333  da0  GPT  (15G)
        34      2014       - free -  (1.0M)
      2048  32356319    1  duracell  (15G)

=>      34  60437425  da1  GPT  (29G)
        34  60437425    1  cache-august  (29G)

=>       34  976773101  da3  GPT  (466G)
         34       2014       - free -  (1.0M)
       2048  976771087    1  Transcend  (466G)

monaco87 said:
… or serial number. …
Click to expand...

Here's another example: Replacing a failing drive in a ZFS zpool – Dan Langille's Other Diary (2020-12-12)
 
As to the question, why FreeBSD does not use the WWN, my personal guess is that there are (were?) some issues with retrieving the WWN, and for this reason not using the WWN by FreeBSD has been become customary.
Like the belief that "/usr" means "Unix System Resources" instead of "user" (see recent discussion), which came up after the original history and reasons got forgotten over passing time.

ralphbsz said:
camcontrol identify /dev/daX
Click to expand...
Just one example: This works only on \[S\]ATA drives.
camcontrol fails on SAS drives, giving this error:
Code: 
camcontrol: ATA ATA_IDENTIFY via pass_16 failed
camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed

So, my personal opinion is that these issues that block[ed] the WWN usage on FreeBSD should be fixed first.
After this has been done, the WWN should imho be used for disk identification like on all other modern OSes.
 
Is the lunid the equivalent of the WWN?
geom disk list Geom name: ada0 Providers: 1. Name: ada0 Mediasize: 250059350016 (233G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r2w2e3 descr: Samsung SSD 850 EVO mSATA 250GB lunid: 5002538d4206bfa9 ident: S33GNX0J604423R rotationrate: 0 fwsectors: 63 fwheads: 16
 
As for to avoid disk renumbering by the bios where adaX becomes adaY or daX becomes daY, it is a good idea to use a gpt label for partitions.
zpool gpt/xxx
I use linux gparted for this as don't know how to do it with freebsd.
 
ralphbsz said:
camcontrol identify /dev/daX
Click to expand...
skunk said:
Just one example: This works only on \[S\]ATA drives.
camcontrol fails on SAS drives, giving this error:
Code: 
camcontrol: ATA ATA_IDENTIFY via pass_16 failed
camcontrol: ATA ATAPI_IDENTIFY via pass_16 failed
Click to expand...
Try camcontrol inquiry daX -S to print the serial number, or camcontrol inquiry daX -SD to print serial number and model name.

I can't check on my (13.0-RELEASE) system if it really displays the serial number. I have only a virtual LsiLogic SAS to work with, here daX devices don't have a serial number assigned to display, it might show up with real hardware.
Code: 
# camcontrol inquiry da0

pass0: <VBOX HARDDISK 1.0> Fixed Direct Access SPC-3 SCSI device
pass0: 300.000MB/s transfers, Command Queueing Enabled
 
T-Daemon said:
… or camcontrol inquiry daX -SD to print serial number and model name. …
Click to expand...

Works for me with FreeBSD 14.0-CURRENT for devices on USB.

Code: 
% lsblk
DEVICE         MAJ:MIN SIZE TYPE                                          LABEL MOUNT
ada0             0:119 932G GPT                                               - -
  ada0p1         0:121 260M efi                                    gpt/efiboot0 -
  <FREE>         -:-   1.0M -                                                 - -
  ada0p2         0:123  16G freebsd-swap                              gpt/swap0 SWAP
  ada0p2.eli     2:37   16G freebsd-swap                                      - SWAP
  ada0p3         0:125 915G freebsd-zfs                                gpt/zfs0 <ZFS>
  ada0p3.eli     0:131 915G -                                                 - -
  <FREE>         -:-   708K -                                                 - -
da0              0:147  15G GPT                                               - -
  <FREE>         -:-   1.0M -                                                 - -
  da0p1          0:148  15G freebsd-zfs                            gpt/duracell <ZFS>
da1              0:169  29G GPT                                               - -
  <FREE>         -:-   1.0M -                                                 - -
  da1p1          0:170  29G freebsd-zfs                        gpt/cache-august <ZFS>
da2              2:56  466G GPT                                               - -
  <FREE>         -:-   1.0M -                                                 - -
  da2p1          2:57  466G freebsd-zfs                           gpt/Transcend <ZFS>
% camcontrol inquiry ada0 -SD
% camcontrol inquiry da0 -SD
pass2: <Generic Flash Disk 8.07> Removable Direct Access SCSI-2 device
pass2: Serial Number YTAI0012080818233298
% camcontrol inquiry da1 -SD
pass3: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device
pass3: Serial Number E0D55EA1C84FF390A9500FDA
% camcontrol inquiry da2 -SD
pass4: <StoreJet Transcend 0> Fixed Direct Access SPC-4 SCSI device
pass4: Serial Number            X3E1SAKRS
% geom disk list
Geom name: ada0
Providers:
1. Name: ada0
   Mediasize: 1000204886016 (932G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r2w2e4
   descr: HGST HTS721010A9E630
   lunid: 5000cca8c8f669d2
   ident: JR1000D33VPSBE
   rotationrate: 7200
   fwsectors: 63
   fwheads: 16

Geom name: da0
Providers:
1. Name: da0
   Mediasize: 16567500800 (15G)
   Sectorsize: 512
   Mode: r1w1e3
   descr: Generic Flash Disk
   ident: YTAI0012080818233298
   rotationrate: unknown
   fwsectors: 63
   fwheads: 255

Geom name: da1
Providers:
1. Name: da1
   Mediasize: 30943995904 (29G)
   Sectorsize: 512
   Mode: r1w1e3
   descr: Kingston DataTraveler 3.0
   ident: E0D55EA1C84FF390A9500FDA
   rotationrate: unknown
   fwsectors: 63
   fwheads: 255

Geom name: da2
Providers:
1. Name: da2
   Mediasize: 500107862016 (466G)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   descr: StoreJet Transcend
   lunid: 5000000000000001
   ident: (null)
   rotationrate: unknown
   fwsectors: 63
   fwheads: 255

% uname -aKU
FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #5 main-n253627-25375b1415f-dirty: Sat Mar  5 14:21:40 GMT 2022     root@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400053 1400053
%
 
mer said:
Is the lunid the equivalent of the WWN?
geom disk list Geom name: ada0 Providers: 1. Name: ada0 Mediasize: 250059350016 (233G) Sectorsize: 512 Stripesize: 4096 Stripeoffset: 0 Mode: r2w2e3 descr: Samsung SSD 850 EVO mSATA 250GB lunid: 5002538d4206bfa9 ident: S33GNX0J604423R rotationrate: 0 fwsectors: 63 fwheads: 16
Click to expand...
I believe Solaris only used the WWN as the device name for SAS2 and FC controllers. Other connections such as direct SATA and SAS1 used the old controller/target/lun (cxtxdx) device name.

On my system using another LSI SAS2 controller (SAS9211-8i) with a single WD Red SATA drive the lunid does indeed match the WWN, and the ident matches the serial number.

For the same setup camcontrol identify da0 gives:

pass0: <WDC WD40EFRX-68N32N0 82.00A82> ACS-3 ATA SATA 3.x device pass0: 600.000MB/s transfers, Command Queueing Enabled protocol ACS-3 ATA SATA 3.x device model WDC WD40EFRX-68N32N0 firmware revision 82.00A82 serial number WD-WCC7K7JKSE5H WWN 50014ee266f13c8f additional product id cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 4096, offset 0 LBA supported 268435455 sectors LBA48 supported 7814037168 sectors PIO supported PIO4 DMA supported WDMA2 UDMA6 media RPM 5400 Zoned-Device Commands no Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes Native Command Queuing (NCQ) yes 32 tags NCQ Priority Information yes NCQ Non-Data Command no NCQ Streaming no Receive & Send FPDMA Queued no NCQ Autosense no SMART yes yes security yes no power management yes yes microcode download yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby yes no write-read-verify no no unload yes yes general purpose logging yes yes free-fall no no sense data reporting no no extended power conditions no no device statistics notification no no Data Set Management (DSM/TRIM) no Trusted Computing no encrypts all user data no Sanitize no Host Protected Area (HPA) yes no 7814037168/7814037168 HPA - Security yes no Accessible Max Address Config no
..... so the WWN is available there also.




So I tried :

gpart create -s gpt /dev/da0 gpart add -t freebsd-zfs -l 50014ee266f13c8f /dev/da0

I now have a device /dev/gpt/50014ee266f13c8f, so I create a pool

zpool create wwn-pool /dev/gpt/50014ee266f13c8f

zpool status wwn-pool gives:

pool: wwn-pool state: ONLINE config: NAME STATE READ WRITE CKSUM wwn-pool ONLINE 0 0 0 gpt/50014ee266f13c8f ONLINE 0 0 0 errors: No known data errors

This looks as close to the old Solaris way as I can get, I'm happy with that. Does anyone see any issues with this?

Thanks for all the replies by the way.
 
"Issues" Nope, no issues at all. The FreeBSD GEOM stuff is very powerful and a very nice abstraction. Toss in the sysctls to control what labels are available for use, you can have things your way.
A lot of discussions wind up saying "Pick one method on your systems and stick with it"; consistency makes later admin easier.
I personally like labeling thing with something identifiable on the outside of the device. Most labels seem to have the serial number, so I usually use that as the gpart label.
 
Just another quick test after that, I export the pool and shut the system down. I then moved the pool disk to port 3 on the controller and connected another blank drive to port 0. On reboot I was able to import the pool without issues.

gpart show -l shows the disk, now on port 3, is still being referenced as da0:

=> 40 7814037088 da0 GPT (3.6T) 40 7814037088 1 50014ee266f13c8f (3.6T)
 
grahamperrin said:
Works for me with FreeBSD 14.0-CURRENT for devices on USB.
Click to expand...
Only with devices that have WWN.
Memory cards do not.

grahamperrin said:
Code: 
   [...]
   descr: StoreJet Transcend
   lunid: 5000000000000001
   [...]
Click to expand...
Beware of bad manufacturers/brands that use fake WWN.

monaco87 said:
On my system using another LSI SAS2 controller (SAS9211-8i) with a single WD Red SATA drive the lunid does indeed match the WWN, and the ident matches the serial number.
Click to expand...
This applies to SAS drives as well.
Seagate SAS drives have printed the WWN on the label on the drive, on HGST drives the label sadly lacks the WWN.

mer said:
"Issues" Nope, no issues at all. The FreeBSD GEOM stuff is very powerful and a very nice abstraction.
Click to expand...
Umm... no issues?
( geom disk list output for drives on a LSI controller, snipped a bit)
Look at da1. Rotationrate and serial number look a bit conspicious to me.
(Will have to look at the label when I have opportunity to shut down the computer.)
Code: 
1. Name: da0
   descr: HITACHI DKR2J-K600SS
   lunid: 5000cca01fa25d24
   ident: J9XW93XL
   rotationrate: 15030
1. Name: da1
   descr: SEAGATE ST3600057SS
   lunid: 5000c500056d6aaf
   ident: 3SL09LTQ00009023ELZ3
   rotationrate: unknown
1. Name: da2
   descr: HITACHI DKR2J-K600SS
   lunid: 5000cca01faef0c4
   ident: J9Y36JWL
   rotationrate: 15030
1. Name: da3
   descr: SEAGATE ST3600057SS
   lunid: 5000c5003c08dfdb
   ident: 6SL1AZKV
   rotationrate: 15000
 
skunk said:
Only with devices that have WWN.
Click to expand...

Were the standard inquiry data and serial numbers not correct in my case?

Code: 
% camcontrol inquiry da0 -SD
pass2: <Generic Flash Disk 8.07> Removable Direct Access SCSI-2 device
pass2: Serial Number YTAI0012080818233298
% camcontrol inquiry da1 -SD
pass3: <Kingston DataTraveler 3.0 > Removable Direct Access SPC-4 SCSI device
pass3: Serial Number E0D55EA1C84FF390A9500FDA
% camcontrol inquiry da2 -SD
pass4: <StoreJet Transcend 0> Fixed Direct Access SPC-4 SCSI device
pass4: Serial Number            X3E1SAKRS

camcontrol(8)
 
skunk said:
Umm... no issues?
Click to expand...
keeping in context, from #19:
"This looks as close to the old Solaris way as I can get, I'm happy with that. Does anyone see any issues with this?"
so I maintain "no issues". OP is gpart labelling based on info from geom disk list, using lunid for the identifier.
That is not the rotation rate and serial no. Your example actually supports "lunid from geom list applied as gpart label is consistent"

Your lunid from geom list looks like it would be consistent if you used it as the argument to gpart -l.
 
You must log in or register to reply here.
Back
Top