huh

I have never seen that before haha

I think that all makes sense though

it's sd, a SCSI disk, etc

Did you find where in the code we emit the "is unformatted" message you got?

How do we decide to print that out

jclulow is a pointer to a function 1 int (*op_ck_format)(); /* check format - mandatory */ ~/smartos-live/projects/illumos/usr/src/cmd/format/hardware_structs.h I'm checking where it points to

Ah, that seems like a member of "struct ctlr_ops" in "cmd/format/hardware_structs.h"

jclulow this could be the one github.com/illumos/illumos-gate/blo…r/src/cmd/format/disk_generic.c#L83

It's SCSI right

It might be ... github.com/illumos/illumos-gate/blo…src/cmd/format/ctlr_scsi.c#L97-L105 ?

You could try something like:

dtrace -x switchrate=1000hz -q -n 'pid$target::*_ck_format:return { printf("\nRETURN: %s() -> %d\n", probefunc, arg1); }' -c format

to know for sure

mm.icann.org/pipermail/tz-announce/2023-March/000077.html - fyi for those with users who care about timezones in Egypt, Morocco, & Palestine as we hit the fun period where DST intersects with Ramadan

Thanks alanc, just saw that myself a little bit back.

unfortunately i don't have an NVMe device that supports namespaces, but IIUC, if multiple namespaces exist on an NVMe device, each namespace would show up as a separate disk in the os, right?

(assuming yes), is there an easy way to map the /dev/[r]dsk device back to the specific nvme device?

yes

you mean getting the instance number of the nvme device?

yeah -- basically if you have a /dev/[r]dsk name of an nvme device and need to do an nvme admin ioctl on it

since I can't experiment.. does each ns show up in /dev/[r]dsk with the same target, but different lun (d) values?

yes, thats the idea

ahh ok

but only usable namespaces will show up as /dev/[r]dsk

and, `nvmeadm -v list` shows unallocated namespaces, which I found useful for something recently

hmmm, not different luns, but different targets, right?

hm

jbk: also, if you have vmware hypervisor, "disks" attached to the same emulated nvme controller will show up as namespaces (not that you can manage them)

yes, maybe you're right. same controller number, different targets

jbk: code.illumos.org/c/illumos-gate/+/2624 patchset 3 is working for me even with -d sat,12. Thanks for fixing this!

→ CODE REVIEW 2624: 15366 ATA PASS-THROUGH (16) is broken (NEW) | illumos.org/issues/15366

jbk: to map to instances, look at: nvmeadm list -p -o instance,disk

I believe

We finally got a parseable mode recently

likely -o namespace,disk, otherwise it lists e.g. nvme0:c2t1d0, nvme0:c2t2d0

sommerfeld: cool.. sorry about the initial goof up.. i thought I had retested that already.. but man between the SATL spec and the ATA spec.. soooo confusing (though hopefully the new code is a bit clearer with how things map)

(it doesn't help that ATA does stuff like 'well if the moon is waxing, then the value is in this field, but when it's waning the same semantic value is in this other field instead)

I still think someone with real scsi and/or ATA experience should look at it, but, well, it's working..

yeah, I can wait (if we can find someone)... I'm running it on my home server

possibly trisk?

who I think might be at racktop still?

jbk: the encoding reminds me a bit of PA-RISC immediate constant encoding. a 21-bit immediate value isn't just pasted into the instruction as is; it's instead sliced into 5 bitfields which are then shuffled around and pasted back together.

ARM does this at times too

but sparc also had unthinkably large immediates that.

ARM also has bitfield magic that andyf had fun with in the disassembler, where they're sort of RLEd?

ARM prefers constant islands

[illumos-gate] 15495 sun_fc: void operator delete(void*) called -- Toomas Soome <tsoome⊙mc>

i never got to look at PA-RISC assembly.. just used to maintain some HP-UX systems

my recollection was despite them having heat sinks that'd make the biggest overclocker jealous, you breathed on them wrong and they'd fail due to heat damage