gitlab.freedesktop.org/dbus/dbus/-/merge_requests/510 may also be of interest to people who build dbus for illumos

Hi & good day.

hrm...

if you have to reformat a drive from 512<->4k block sizes (a number of drives let you do this via the FORMAT DISK command)... the kernel still caches the old block size

which can be problematic for things like trying to label a disk..

is there an easy way to kick the kernel into refreshing it's info?

I'm guessing this is probably somewhere in/adjacent to the cmlb driver

(I'll source dive if needed, but thought someone might know offhand)

does it actually format to 4kn or to 512e (that is 512/4096) mode?

AFAIK, it does do 4k

it's an SSD, so I suspect it's natively 4k, but can do 512e

hmm.. it does look like maybe doing a GETEFI will force a re-read (even if it fails after that since there wouldn't be a label there)

it's native erase block size is likely 128K or bigger. real question is how much write amplification a 512-byte write will trigger.

the kernel caches value in device-blksize property, so effectively either it need to update this property or reload the disk instance (and update properties related to this disk)

also.. i should probably file a ticket for us to stop issuing READ(6) and WRITE(6) CDBs given they've been deprecated for decades at this point

(I did that for scsi_vhci since we encountered a disk that got rather 'upset' at those)

sounds reasonable

or maybe disable it, and selectively allow with a device property if someone has an absolutely prehistory SCSI device that can't handle READ(10)/WRITE(10) CDBs for smaller LBAs (but then chances are $20 will get you a new disk that doesn't have the problem and is probably a couple of orders of magnitude larger)

heh, that reminds me how in my alma mater we did hook up disk box from sun3 to something more recent to be used as storage space for squid and those two disks in that cage were in use years after sun3's were powered off:P

i'd need to look again, but i think those CDBs were deprecated in the early 2000s

i think it's probably in the scsi_vhci ticket

sounds like 'no one expects the Spanish inquisition' ;)

[illumos-gate] 17546 old ZFS resilver and scrub tuneables no longer do anything? -- Toomas Soome <tsoome⊙mc>

is there a reason our RAND_MAX is 0x7fff and not 0x7fffffff? Other reason than historical, I mean..

I suspect you'd need new symbols if you changed it

no I haven't changed. Also, I do not really believe we need new symbols, because according to pubs.opengroup.org/onlinepubs/009696699/functions/rand.html, "The value of the {RAND_MAX} macro shall be at least 32767." and rand()/rand_r() return int.

it's still going to break expectations of existing binaries if rand() returns a value greater than the RAND_MAX they were compiled with.

well, I guess, the question would be, is that actually a problem?

I did step on this reviews.freebsd.org/D23290 and started to wonder...

[illumos-gate] 17561 fix assert.h Makefile check target -- Robert Mustacchi <rm⊙fo>

sommerfeld: Right, I think it would be unsafe to assume you could change the value after the fact

People will absolutely have done something with it, for sizing things, or dividing and normalising

tsoome: changing RAND_MAX from 0x7ffffffd to 0x7fffffff (what FreeBSD did) is less likely to break things than changing it from 0x7fff to 0x7fffffff

maybe;) but they have much better medicine for such breakage.

(just probabalistically, only about one in two billion calls would exceed 0x7ffffffd, whereas 99.99% of calls would exceed 0x7fff)

People ought to just use arc4random(3C) instead, these days

Using arc4random_uniform() is probably better than whatever people tended to be doing with RAND_MAX anyway

its not really about what they should use, its about what we do provide.

right, that's why bill is being conservative with it

Right

as long as arc4random_* isn't actually built out of RC4 ...

It's an unfortunate name for an otherwise well considered facility haha

didn't we port it from openbsd?

(and by we, i'm guessing it was probably arekinath)

I think it was rmustacc

But yes, I believe it came from OpenBSD

oh.. 50/50 odds :)

Along with the getrandom(2)/getentropy(3C) stuff that sits underneath

if I recall, openbsd arc4random used to use the alleged rc4 but moved to something better

wikipedia says BSD used chacha, apple aes

github.com/illumos/illumos-gate/blo…/src/lib/libc/port/gen/arc4random.c seems to heavily suggest it's using chacha

illumos.org/issues/5830 states it explicitly.

→ FEATURE 5830: want arc4random(3C) suite (Closed)

We use chacha20, yes.

[illumos-gate] 16377 pcieadm show-devs output incorrect for dev with no current-width property -- Robert Mustacchi <rm⊙fo>

tsoome: so in any event the way to go if you really want to change RAND_MAX is to alias the symbol at compile time and have libc export both.

Yeah

the bottom part of pastebin.com/FjZzw5cG is a list of small nits in the illumos man pages if anyone is bored and wants to help fix them (I already sent directly to ptribble)

thanks alanc !

btw, dbus upstream merged the Solaris+illumos meson build fixes patch today, not yet the event ports patch