[illumos-gate] 16034 idmap core dumps with preferred_dc set -- Matt Barden <mbarden⊙rc>

[illumos-gate] 15512 zfs: Check the dataset type more rigorously when fetching properties. -- Tim Chase <tim⊙cc>

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

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)

[illumos-gate] 15970 SMB2 QueryInfoFile level FileAllInformation could be more efficient -- Matt Barden <mbarden⊙rc>

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.

This was a problem say with mpt_sas, when you need a contig allocation to the device.

Let me see if I can dig up an example ticket.

So this generally isn't legacy per se. But depends on a lot of specifics.

That was a problem I hit with determining the maximum transfer size when we were doing the WDC e6dump commands via mpt_sas.

So an example jbk is illumos.org/issues/8235 and github.com/TritonDataCenter/rfd/blob/master/rfd/0031/README.md.

→ FEATURE 8235: fwflash for sd needs to handle partial writes (Closed)

rmustacc: ahh ok..

There may still be things that we can improve here and the specifics will matter.

At times like this I'm happy illumos has a more conservative approach to pull in things from OpenZFS. openzfs/zfs #15526 seems nasty especially since it defaulted to on (why default to on??)

[illumos-gate] 16079 rsrvrctl could be consistent with memory size units -- Jordan Paige Hendricks <jordan⊙oc>

the flip side is for anything non-trivial it can be very hard to pull things in piecemeal w/o missing something

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)

that maybe allow us to keep up easier without living too dangerously

sjorge we are not really conservative, we are just missing people.

ah, the block cloning

yep

Well we are missing a lot of older stuff too yeah

But I also meant more in generally

e.g. if something goes in that turns out to be broken, we do back it out again

I would have to say that if there's an area where you want to be conservative, zfs would likely be it

Who's planning to go to FOSDEM 2024?

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

nothing set in stone, yet but i assume a few people from OmniOS will be there like every year

I haven't booked anything yet (was just looking) but am planning to be there

sjorge oh yeah, is better to have stability that adding changes, as you say slow paced is really better

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

it was my first time running zfs tests, maybe I did not read that was a --dry-run option or something like that.