01:09:15 https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/510 may also be of interest to people who build dbus for illumos 09:57:53 Hi & good day. 15:59:47 hrm... 16:01:12 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 16:01:22 which can be problematic for things like trying to label a disk.. 16:01:37 is there an easy way to kick the kernel into refreshing it's info? 16:01:57 I'm guessing this is probably somewhere in/adjacent to the cmlb driver 16:02:16 (I'll source dive if needed, but thought someone might know offhand) 16:48:40 does it actually format to 4kn or to 512e (that is 512/4096) mode? 16:52:48 AFAIK, it does do 4k 16:53:05 it's an SSD, so I suspect it's natively 4k, but can do 512e 16:53:49 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) 16:54:40 it's native erase block size is likely 128K or bigger. real question is how much write amplification a 512-byte write will trigger. 16:54:47 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) 16:59:36 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 17:00:40 (I did that for scsi_vhci since we encountered a disk that got rather 'upset' at those) 17:01:25 sounds reasonable 17:02:14 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) 17:05:07 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 17:07:33 i'd need to look again, but i think those CDBs were deprecated in the early 2000s 17:07:43 i think it's probably in the scsi_vhci ticket 17:10:00 sounds like 'no one expects the Spanish inquisition' ;) 17:13:20 [illumos-gate] 17546 old ZFS resilver and scrub tuneables no longer do anything? -- Toomas Soome 18:29:07 is there a reason our RAND_MAX is 0x7fff and not 0x7fffffff? Other reason than historical, I mean.. 18:47:34 I suspect you'd need new symbols if you changed it 19:23:20 no I haven't changed. Also, I do not really believe we need new symbols, because according to https://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. 19:33:52 it's still going to break expectations of existing binaries if rand() returns a value greater than the RAND_MAX they were compiled with. 19:35:55 well, I guess, the question would be, is that actually a problem? 19:48:50 I did step on this https://reviews.freebsd.org/D23290 and started to wonder... 20:02:23 [illumos-gate] 17561 fix assert.h Makefile check target -- Robert Mustacchi 20:03:58 sommerfeld: Right, I think it would be unsafe to assume you could change the value after the fact 20:04:15 People will absolutely have done something with it, for sizing things, or dividing and normalising 20:40:00 tsoome: changing RAND_MAX from 0x7ffffffd to 0x7fffffff (what FreeBSD did) is less likely to break things than changing it from 0x7fff to 0x7fffffff 20:42:31 maybe;) but they have much better medicine for such breakage. 20:52:22 (just probabalistically, only about one in two billion calls would exceed 0x7ffffffd, whereas 99.99% of calls would exceed 0x7fff) 20:52:25 People ought to just use arc4random(3C) instead, these days 20:53:05 Using arc4random_uniform() is probably better than whatever people tended to be doing with RAND_MAX anyway 20:53:17 its not really about what they should use, its about what we do provide. 20:53:39 right, that's why bill is being conservative with it 20:53:42 Right 20:54:24 as long as arc4random_* isn't actually built out of RC4 ... 20:54:52 It's an unfortunate name for an otherwise well considered facility haha 20:55:32 didn't we port it from openbsd? 20:55:41 (and by we, i'm guessing it was probably arekinath) 20:55:46 I think it was rmustacc 20:55:56 But yes, I believe it came from OpenBSD 20:55:58 oh.. 50/50 odds :) 20:56:12 Along with the getrandom(2)/getentropy(3C) stuff that sits underneath 20:57:38 if I recall, openbsd arc4random used to use the alleged rc4 but moved to something better 20:58:19 wikipedia says BSD used chacha, apple aes 21:03:25 https://github.com/illumos/illumos-gate/blob/master/usr/src/lib/libc/port/gen/arc4random.c seems to heavily suggest it's using chacha 21:14:55 https://www.illumos.org/issues/5830 states it explicitly. 21:14:56 → FEATURE 5830: want arc4random(3C) suite (Closed) 21:32:57 We use chacha20, yes. 21:43:03 [illumos-gate] 16377 pcieadm show-devs output incorrect for dev with no current-width property -- Robert Mustacchi 21:57:48 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. 22:35:16 Yeah 22:47:19 the bottom part of https://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) 23:27:40 thanks alanc ! 23:51:20 btw, dbus upstream merged the Solaris+illumos meson build fixes patch today, not yet the event ports patch