04:38:04 [illumos-gate] 12023 zfs test zfs_written_property_001_pos can fail -- Bill Sommerfeld 08:15:41 Apparently opengrok is under attack from something horrendous called "ClaudeBot/1.0; +claudebot⊙ac" 08:15:57 I have blocked that off... and also it's in a bigger instance with a newer CPU etc 08:16:02 So hopefully things are better now 08:18:06 thanks! 10:12:46 [illumos-gate] 16521 ipf kernel panic while initialising statistics on low memory system -- Andy Fiddaman 12:53:52 great opengrok is back 13:52:20 jclulow: looks like other people have observed the same: https://www.reddit.com/r/singularity/comments/1cdm97j/anthropics_claudebot_is_aggressively_scraping_the/ 14:14:19 https://github.com/Seagate/openSeaChest mentiones illumos support? Has anyone got this to work ? 14:14:41 yes 14:15:09 though we've only used it against scsi devices 14:15:35 it wouldn't surprise me if the nvme stuff doesn't work on illumos 14:17:27 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 14:17:39 SCSI or SATA? 14:17:46 SAS 14:17:56 i think that should work 14:18:15 Hooked up to either an LSI HBA or a Broadcom HBA, I can swap it between chasis to configure it if needed 14:18:29 Cool, I guess I have to figure out how to build it then 14:18:45 it's using uscsi, so the HBA _shouldn't_ matter as long as it's JBOD 14:20:02 Yeah JBOD, don't see the point of HW RAID when we got ZFS 14:20:15 And even then, HW RAID is ick 14:21:33 But good to know someone has used it at least 14:22:55 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." 14:24:55 my guess is with the recent nvme passthru support, we could probably support more if the code was written to utilize it 14:25:43 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) 14:28:30 i've been working on a bunch of sata improvements that i'll hopefully get up for review soon(ish) as well 14:40:11 libnvme isn't quite at a promised stable interface yet today. 17:23:57 I recently hit the problems that jperkin mentioned a while back about int8_t being char rather than explicitly signed char 17:24:18 See the log of the discussion here: 17:24:21 https://log.omnios.org/illumos/2023-02-01#1675272145-499103 17:25:01 Just wondering if this is something that should be fixed properly? 17:27:18 yes, it should. 17:27:57 do you know if there is a bug open? 17:30:32 I can't immediately spot one 17:31:43 so was this specifically being broken for C++ ? 17:31:55 or some other breakage? 17:33:00 It's C++, specifically Apache Arrow in this case 17:39:01 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..) 17:43:45 I suspect it could cause pain, in my test changing the type changes the mangled symbol names 17:45:23 that makes sense 17:46:18 "rebuild all C++" is something that people doing C++ are at least sort of used to. 17:57:40 Logged https://www.illumos.org/issues/16523 17:57:41 → BUG 16523: int8_t should explicitly be signed char (New) 18:26:36 ptribble: I've been running with that change for ages, I've yet to see or hear of any fallout 18:26:56 it fixes a bunch of software 18:43:52 Maybe worth getting it up then jperkin given the practical experience which is where I'd have most of my questions. 18:47:35 I also have to do that on ARM (where char is unsigned) 18:47:44 so to the extent omnios on arm exists, that does it too 18:48:20 andyf actually gave me the rundown on C++ being a pain in the ass about this, but I forgot if there were more details 18:48:36 (who really had internalized that 'char', 'signed char' and 'unsigned char' all mangle differently?) 18:49:18 I see, so this may break the C++ ABI for apps then. :/ 18:51:24 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 18:51:58 been running it since Feb 2023 18:54:25 richlowe: i'm pretty sure I knew at one point when i was working on the demangler, then subsequently (deliberately?) forgot about it 18:59:12 okay, random possibly hairbrained thought: any way to construct some sort of symbol aliases for differently-mangled names? 19:00:22 Probably, but none of that is in illumos-gate. 19:45:21 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 20:28:59 i supposed you could run them through the demangler and grep for 'char' or such.. 20:29:02 -d 20:41:52 if you have the old .so and the new one I think it wouldn't be too bad. 20:42:33 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? 20:48:42 If you're rebuilding/updating a library, then rebuilding consumers would avoid the need to do anything, and is fairly common practice anyway 20:50:51 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 20:51:41 So you may as well bite the bullet and declare a rebuild the (C++) world flag day 20:52:00 If only there were a tool that would rebuild everything that was dependent on something that changed. 20:54:46 yeah, if someone could make such a tool, that'd be pretty neat 20:55:20 Hey, "make" would be a great name for it, wouldn't it? 20:59:58 When I build stuff I actually check if any symbols have disappeared from shared libraries, so I know whether I need to rebuild consumers