jclulow: Regarding what veg brought up a few days ago according to the channel logs, I am of the opinion that illumos and the broader OpenZFS community do not do enough networking at things like Illumos Day (when was the last one?), the OpenZFS developer summit, etcetera. Some networking would probably help, especially since there were some patches done specifically for the sake of improving compatibility

with illumos a few months back.

openzfs/zfs 0e4c830 openzfs/zfs cf66e7e

We don't really hold regular events

And I'm not planning to go to any in person conferences any time soon

jclulow: Also, were any of my follow-up emails explaining my analysis of that thing that I suspect people here would rather I say less about helpful?

I'm still reading through them, I'll get you a response soon

Okay.

wrt. to the ZFS summit I was somewhat surprised it was in person this year -- I would have tried to attend if it were online

But I've also been astoundingly busy at work

I haven't been intentionally skipping the monthly call, but I also don't feel like I'm in a position to offer much guidance there because we're so far apart at this point

Regarding the monthly call, I keep forgetting due to being busy too. I need to add it to my schedule.

As for getting closer, I have made a few efforts to reduce differences on the OpenZFS repository side. Beyond those two patches, there was also this one that removed a bunch of ZoL specific changes from the code: openzfs/zfs fdc2d30

Wait... that might be the wrong patch. One moment.

This is it: openzfs/zfs ab8d9c1

Many ZoLisms were removed by that.

That might make porting more painful due to the historical patches not being fixed, but at some point, it should start making things easier.

Some feedback on this would also be nice: openzfs/zfs 3036783

The naming is bad, but it fixed a potential problem. I was told to name it kmem_scnprintf() and given the lack of disenting opinions that name won. It could still be changed. In both XNU and Linux, a functionally identifical function is named scnprintf(), but I did not want to cause confusion if illumos were to begin using that name to mean something else...

I also did not know that the function was called that at first. I made it independently and then was told that I had reinvented scnprintf(). ^_^;;

I also gave the wrong link for that one. This is the patch introducing it that I meant to link: openzfs/zfs 97143b9

I have written so many patches over the past 4 months that I am losing track of which is which.

The sheer quantity of patches in ZOL is part of what makes it hard to keep up to be honest

I expect if we're going to try to get up to date we'll need to re-port the whole codebase rather than trying to add patches piecemeal

Which obviously is a lot of work and presents tremendous risk in a critical component

jclulow: Well, there is always the possibility of doing what FreeBSD did so that the development tree and stable releases always support illumos and you can grab the latest driver with little to no effort on your part, after the initial big effort in getting it working in the first place.

Yes I expect we would look at something like that

The big effort is the hardest part haha

Once it is working, we would be running the test suite on illumos on every PR, so support should stay working.

Well, you are not alone. I am sure myself and others would be willing to do some pair programming on it.

The biggest headache with a port, is that you kind of need another filesystem in tree to use to avoid having ZFS be the rootfs, since doing surgery on the rootfs driver is a painful experience when the inevitable mistake occurs that compiles, but utterly breaks it. I hope UFS is still in decent shape.

That could just be my Linux experience speaking since Linux will keep going even if a filesystem has effectively crashed via a NULL pointer dereference or similar issue that would panic another kernel.

That's absolutely terrifying

Well, it makes debugging easier in some cases since the thread where the bad thing happened basically is frozen in time and I can attach a debugger to the system from userland to examine it.

No need to deal with crash dumps, or do special configurations to attach a debugger to the machine over a serial line.

s/thing happened/thing that happened/

There's literally no way to trust the computer though

Anyway this is obviously a cultural difference haha

Well, it works when it is inside the filesystem driver and the mount points involved are not related to your rootfs where your tools are. It might be less applicable outside of that area.

I heard that it was a result of Linus Torvalds not liking debuggers. Anyway, as long as it works...

Also, the technique was useful for a "hang" that was not really a bug. I had a pool that was so severely damaged by my testing that involved a corruption issue due to bad hardware, that async destroy stopped working. Examining the machine live let me realize that I could set a certain module parameter and it would unstick itself.

Which I got to see right in front of my eyes.

My goal there was to make ZFS even more resilient against bad hardware... it has been a slow and painful process, although I am getting closer.

Note that this is a special kind of bad hardware that just returns errors on flushes in a single massive event because it killed all of the in-flight data and not a "I am consistently malfunctioning" kind of bad hardware.

That case is rare, but it can break the expectation that fsync returning okay means the data is safely on disk because the txg_sync commit's references to the fsynced data got destroyed, yet we have enough information that we can handle that situation in theory with some changes to track what was written since the last successful flush and re-execute it when we know that there was a problem with a flush. At

least that is the idea.

jclulow: This mailing list thread where Linus Torvalds is vehmently against things like kernel debuggers and crash dumps might explain some things: lkml.org/lkml/2000/9/6/65

I am familiar with it haha

Linux eventually got them in crippled forms and the end result is that I debug Linux via its own userland since dealing with the headaches from trying to get the stars to align properly from poorly maintained debug tools are more trouble than attaching a mdb-like tool Delphix made to the running kernel to be able to poke around.

In the past, I would attach gdb via QEMU after reproducing the issue, but gdb took many hard to get right commands to do what Delphix's sdb enables me to do with ease.

Seems that RTL8153 (USB3 to Ethernet) is newish chip and that support is not included out of box in illumos..

nikolam: That is correct. There is currently no support for the device.

Something seems very wrong with /opt/zfs-tests/tests/functional/removal/remove_mirror

Has anyone run this recently?

oh, well this explains why it has stopped

zfs_removal_suspend_progress: 1

ohhhh boi, I just was playing around with github.com/authzed/spicedb and found out about this new thing called 'xDS' envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol and now I'm so confused

Anyone using xds? trying to understand what was broken / lacking with load balancing that makes this a requirement for my brain cycles

tsoome_: do you need me to do anything about #pragma ident, or are folks going with it?

andyf: did dan hit that problem too?

the zfs tests are so spotty :*

uh, :(

you mean 15280?

I feel like I need a "learning a weird keyboard" warning sticker

tsoome_: yeah, I didn't know I need to be loudly in favor of it or not :)

(I am)

richlowe - I don't know, but it looks like a previously aborted test run left that variable set in the kernel

I havent seen feedback yet:)

disabling -zcompstrtab by default would make me happy, and things faster

Once I reset it, things ran better

but if I do it with idents around, .comment can get mindbogglingly huge

headers,

but, the good thing is, I should have cleanups done and I'm doing verification builds atm

but for eg oxide have had problems were rust-y things make compressing the compressable string sections the slowest thing we do

haskell also can get into that place

How weird a keyboard?

so you might be enabling a nice perf win by getting rid of the only downside :)

current nightly is running with "cw: remove -fident flag"