05:55:00 [illumos-gate] 16034 idmap core dumps with preferred_dc set -- Matt Barden 07:14:13 [illumos-gate] 15512 zfs: Check the dataset type more rigorously when fetching properties. -- Tim Chase 16:15:56 this is probably a bit vague, but there's lots of cases in the kernel where we seem to do things like limit DMA sizes on 'x86', or (like in the emlxs driver) seem to limit the max scsi transfer size on x86 (only)... i'm wondering if those are just 32-bit kernel artifacts, or is there some other legacy thing 16:20:59 e.g. sd.c has some amount of '#if defined(__x86)' that aren't immediately obvious why (or at least if it there is an explanation, i haven't found it yet -- which given the size of the scsi code, is quite possible) 16:51:31 [illumos-gate] 15970 SMB2 QueryInfoFile level FileAllInformation could be more efficient -- Matt Barden 17:03:46 So the biggest difference between the platforms is the lack today of an IOMMU on x86, which means that device limits are more readily apparent. 17:04:02 This was a problem say with mpt_sas, when you need a contig allocation to the device. 17:04:13 Let me see if I can dig up an example ticket. 17:05:51 So this generally isn't legacy per se. But depends on a lot of specifics. 17:07:43 That was a problem I hit with determining the maximum transfer size when we were doing the WDC e6dump commands via mpt_sas. 17:08:41 So an example jbk is https://www.illumos.org/issues/8235 and https://github.com/TritonDataCenter/rfd/blob/master/rfd/0031/README.md. 17:08:42 → FEATURE 8235: fwflash for sd needs to handle partial writes (Closed) 17:25:59 rmustacc: ahh ok.. 17:26:41 There may still be things that we can improve here and the specifics will matter. 18:37:15 At times like this I'm happy illumos has a more conservative approach to pull in things from OpenZFS. https://github.com/openzfs/zfs/issues/15526 seems nasty especially since it defaulted to on (why default to on??) 18:50:55 [illumos-gate] 16079 rsrvrctl could be consistent with memory size units -- Jordan Paige Hendricks 19:13:53 the flip side is for anything non-trivial it can be very hard to pull things in piecemeal w/o missing something 19:15:08 though maybe if we were to sync up with a slightly older version and then just periodically roll forward (a non trivial amount of effort on it's own to be sure) 19:15:58 that maybe allow us to keep up easier without living too dangerously 20:44:28 sjorge we are not really conservative, we are just missing people. 20:49:09 ah, the block cloning 20:49:23 yep 21:08:51 Well we are missing a lot of older stuff too yeah 21:08:59 But I also meant more in generally 21:09:39 e.g. if something goes in that turns out to be broken, we do back it out again 21:11:45 I would have to say that if there's an area where you want to be conservative, zfs would likely be it 22:17:44 Who's planning to go to FOSDEM 2024? 22:22:35 since it looks like we don't have a table, it would depend on who's going when and if it's snowing or not for me 22:29:24 nothing set in stone, yet but i assume a few people from OmniOS will be there like every year 22:32:30 I haven't booked anything yet (was just looking) but am planning to be there 22:35:31 sjorge oh yeah, is better to have stability that adding changes, as you say slow paced is really better 22:39:09 jbk last time I added some changes from openzfs, running the tests I destroyed my vms I think I passed the wrong disks, I should complete a couple of changes that I pulled from openzfs 22:58:17 it was my first time running zfs tests, maybe I did not read that was a --dry-run option or something like that.