[illumos-gate] 12023 zfs test zfs_written_property_001_pos can fail -- Bill Sommerfeld <sommerfeld⊙ho>

Apparently opengrok is under attack from something horrendous called "ClaudeBot/1.0; +claudebot⊙ac"

I have blocked that off... and also it's in a bigger instance with a newer CPU etc

So hopefully things are better now

thanks!

[illumos-gate] 16521 ipf kernel panic while initialising statistics on low memory system -- Andy Fiddaman <illumos⊙fn>

great opengrok is back

jclulow: looks like other people have observed the same: reddit.com/r/singularity/comments/1…udebot_is_aggressively_scraping_the

github.com/Seagate/openSeaChest mentiones illumos support? Has anyone got this to work ?

yes

though we've only used it against scsi devices

it wouldn't surprise me if the nvme stuff doesn't work on illumos

I had to replace a drive that failed and went with an EXOS that was bigger, but want to set the block size to 4k instead of 512E

SCSI or SATA?

SAS

i think that should work

Hooked up to either an LSI HBA or a Broadcom HBA, I can swap it between chasis to configure it if needed

Cool, I guess I have to figure out how to build it then

it's using uscsi, so the HBA _shouldn't_ matter as long as it's JBOD

Yeah JBOD, don't see the point of HW RAID when we got ZFS

And even then, HW RAID is ick

But good to know someone has used it at least

jbk: the readme says about seachest support of nvme on illumos: "No, but possible | Been a while since last looked at, but appeared limited in what commands were available."

my guess is with the recent nvme passthru support, we could probably support more if the code was written to utilize it

i think for SATA it uses the SCSI SATA pass-thru cmd, so I think that should work fine (esp w/ the fixes to the pass-thru cmd a while back)

i've been working on a bunch of sata improvements that i'll hopefully get up for review soon(ish) as well

libnvme isn't quite at a promised stable interface yet today.

I recently hit the problems that jperkin mentioned a while back about int8_t being char rather than explicitly signed char

See the log of the discussion here:

Just wondering if this is something that should be fixed properly?

yes, it should.

do you know if there is a bug open?

I can't immediately spot one

so was this specifically being broken for C++ ?

or some other breakage?

It's C++, specifically Apache Arrow in this case

I'd file a bug at a minimum and start seeing if there are any unintended consequences of the change (I'd hope fallout would be minimal, but..)

I suspect it could cause pain, in my test changing the type changes the mangled symbol names

that makes sense

"rebuild all C++" is something that people doing C++ are at least sort of used to.

Logged illumos.org/issues/16523

→ BUG 16523: int8_t should explicitly be signed char (New)

ptribble: I've been running with that change for ages, I've yet to see or hear of any fallout

it fixes a bunch of software

Maybe worth getting it up then jperkin given the practical experience which is where I'd have most of my questions.

I also have to do that on ARM (where char is unsigned)

so to the extent omnios on arm exists, that does it too

andyf actually gave me the rundown on C++ being a pain in the ass about this, but I forgot if there were more details

(who really had internalized that 'char', 'signed char' and 'unsigned char' all mangle differently?)

I see, so this may break the C++ ABI for apps then. :/

yeh I have zero confidence in it not breaking stuff which is why I've only had it in my tree, I just know it fixes lots

been running it since Feb 2023

richlowe: i'm pretty sure I knew at one point when i was working on the demangler, then subsequently (deliberately?) forgot about it

okay, random possibly hairbrained thought: any way to construct some sort of symbol aliases for differently-mangled names?

Probably, but none of that is in illumos-gate.

the problem is i think you'd have to figure what all of those symbols are... not sure how big of a task that'd be

i supposed you could run them through the demangler and grep for 'char' or such..

-d

if you have the old .so and the new one I think it wouldn't be too bad.

go through the symbols present in old but not new, see if the same thing with s/char/signed char/ is present in new, and if so, add alias?

If you're rebuilding/updating a library, then rebuilding consumers would avoid the need to do anything, and is fairly common practice anyway

More painful is that if you're compiling a consumer with the new header but the library was build with the old - in that case you're forced into rebuildin the library and all other consumers

So you may as well bite the bullet and declare a rebuild the (C++) world flag day

If only there were a tool that would rebuild everything that was dependent on something that changed.

yeah, if someone could make such a tool, that'd be pretty neat

Hey, "make" would be a great name for it, wouldn't it?

When I build stuff I actually check if any symbols have disappeared from shared libraries, so I know whether I need to rebuild consumers