18:11:20 <gitomat> [illumos-gate] 16812 fsck_pcfs: need to support 4kn sector size -- Toomas Soome <tsoome⊙mc>
18:52:27 <nomad> thanks to whoever fixed the problem that was keeping OmniOS from booting in XCP-ng.
19:02:07 <richlowe> I'm not sure what that would be
19:02:14 <richlowe> off the top of my head
19:11:53 <jbk> XCPng was identifying itself as hyper-v
19:12:03 <jbk> at least that's what I saw
19:29:40 <jbk> although there is also a change related to it's emulated nvme support
19:36:24 <nomad> it was the nvme support that was hosing me when I tried before.
20:19:45 <nomad> I take it ipadm is not the right tool to tell me the negotiated speed on an interface. What command would you recommend for that?
20:20:12 <nomad> (I'm trying to figure out why iperf3 says the network speed is pathetic.)
20:21:11 <richlowe> dladm show-link
20:21:22 <richlowe> oh, no, not that one either
20:21:24 <richlowe> show-phys?
20:21:40 <nomad> LINK         MEDIA                STATE      SPEED    DUPLEX   DEVICE
20:21:41 <nomad> e1000g0      Ethernet             up         1000     full     e1000g0
20:21:57 <jbk> VM? or a physical e1000g interface?
20:22:01 <nomad> VM
20:22:09 <jbk> what hypervisor?
20:22:27 <nomad> and what I'm seeing is a Linux (AlmaLinux 9) VM on the same hypervisor is getting multiple orders of magnitude better results.
20:22:29 <nomad> XCP-ng
20:22:41 <jbk> doesn't it support virtif?
20:23:27 <nomad> jbk, the "NIC type" options are e1000 or RTL8139.
20:23:38 <nomad> Is virtif something I need to set in OmniOS?
20:23:43 <richlowe> I believe we have a para-virt 8139 driver
20:23:47 <nomad> I just did a basic default install.
20:23:52 <richlowe> tho I have no idea about any kind of recent xen
20:24:03 <nomad> richlowe, I get the same (bad) speed with either NIC type.
20:24:10 <richlowe> I just know that when we build i86hvm we build a separate PV 8139
20:24:31 <richlowe> that's the extent of my xen knowledge, unfortunately.
20:24:49 <richlowe> rmustacc: see, 8139, another cockroach nic.
20:24:58 <richlowe> tulip, 8139, 3c509?
20:26:17 <nomad> jbk, my google fu is failing me. I'm not finding any reference to 'virtif' in regard to XCP-ng or OmniOS. I'll keep digging, though.
20:26:35 <richlowe> I think jbk meant vioif 
20:26:45 <richlowe> virtio network interfaces
20:26:57 <nomad> that would explain why I'm not finding it :)
20:35:33 <jbk> err yeah
20:35:48 <jbk> it's been a very long past 2 weeks :)
20:38:10 <nomad> It's still Monday here.
20:38:15 <nomad> A very Mondayish Monday.
20:39:31 <nomad> The whole reason I was looking at this was because I was getting divergent numbers between AlmaLinux 9 (at 9.40 Gbits/sec) and FBSD (at 1.40 Gbits/sec) so I thought I'd add another non-Linux into the mix to see if I saw similar results.
20:39:44 <nomad> I didn't expect it to be 97.8 Mbits/sec though.
20:39:54 <nomad> (All using exactly the same iperf3 command.)
20:40:05 <nomad> (all VMs running on the same hypervisor)
20:43:11 <neuroserve> nomad : all with the same network driver?
20:46:36 <nomad> all with the e1000 device, yes.
20:48:06 <richlowe> e1000g is one of the drivers I would have bet on not being slower than necessary
20:48:14 <richlowe> given the sun systems it shipped in :\
20:50:50 <nomad> I just installed this VM using a fresh download of OmniOS 151050. Everything was set to defaults.
20:51:25 <nomad> (and yes, I did patch :)
20:51:47 <nomad> but that doesn't mean this isn't a tuning problem.
20:56:05 <nomad> Unlikely thing: there's no XEN management agent for this OS (that I can find, anyway) and that sets rate limits. I presume with no agent there are no rate limits, not all the rate limits.
21:02:34 <richlowe> can someone confirm for me that the `findroot` test skips on x86 too? I think it's because `user=root` lacks the spaces, maybe?
21:04:53 <nomad> richlowe, is this a test I can run for you? I'd need some context :)
21:09:24 <richlowe> it's one of the tests in the util-test suite, but I'd hoped someone had run it recently and could just look :)
21:09:47 <richlowe> it's going to be a couple hours before they all finish on (emulated) arm.
21:15:35 <sommerfeld> richlowe: it has a dependency on idmap
21:16:08 <sommerfeld> if [ $(svcs -H -o state svc:/system/idmap) != "online" ]; then
21:16:09 <sommerfeld>     echo "svc:/system/idmap not enabled and online; can't do SID-to-UID mapping" >&2
21:16:09 <sommerfeld>     exit 4
21:16:09 <sommerfeld> fi
21:16:38 <sommerfeld> the test is new with 16546
21:22:09 <richlowe> sommerfeld: thanks, I'll check if that's what's happening
21:22:44 <sommerfeld> for me, on x86, it will PASS if idmap is enabled, and SKIP if it's disabled.
21:29:51 <richlowe> it was that, it now flipped to FAIL, I'll look into that separately and assume it's aarch64 related
21:30:43 <richlowe> I can show you the log, if you think it might help, but it didn't help me.  (...and the nature of running in an emulator like this makes it very very prone to races)
21:38:44 <sommerfeld> I can take a look
21:40:03 <sommerfeld> might point towards which thing isn't working.
21:40:05 <richlowe> https://gist.github.com/richlowe/446398fafbb785a7aad2337c5f8fa3dd
21:42:01 <sommerfeld> ah, it mostly worked, except for -sidacl which is the most complicated variant.
21:43:44 <sommerfeld> (it maps the sid to both a uid and a gid and looks for both in acl entries)
22:00:48 <sommerfeld> what's really odd is the "/root" in the actual output of the second one.   that points more towards something being off in the shell.
22:01:36 <sommerfeld> it does everything in a temporary directory that should only have four entries (a b c d)
22:03:13 <richlowe> that is surprising, I'll run it with -x and look at it assuming it's a bug here.
22:04:23 <richlowe> what I especially don't understand is that I would imagine `find . ...` to always give output beginning ./
22:20:26 <richlowe> sommerfeld: the `/root` is the text from `cd -`, the 2nd find invocation found nothing.
22:28:00 <richlowe> sommerfeld: I updated the gist with ls -lV of the test directory, but it looks like something larger (and no doubt specific to arm) must be wrong, to me.
22:31:28 <nomad> FTR: a colleague of mine did a similar test using OmniOS 151050 on an ESXi server that also should have 10G available and got: at 0.00-60.00 sec, 5.66 GBytes, 811 Mbits/sec
22:31:46 <nomad> much better than mine, but still much slower than would be expected.
23:24:54 <sommerfeld> richlowe: ah, d'oh.
23:32:12 <sommerfeld> richlowe: something's definitely off with id mapping somewhere.   I see "sidb" (4*-5*-6*) appearing on all four files when I'd expect it only on files b and d, with "sida" (1*-2*-3*) on a and c..
23:34:15 <sommerfeld> idmap dump -v and ls -lnn may also be informative.
23:58:06 <jbk> nomad: w/ e1000g or vmxnet3s?
23:58:43 <nomad> jbk, he tested both. I'm working on a writeup now.
23:58:54 <nomad> the 5.66 was with e1000
23:59:18 <nomad> he got 28.5 Gbits/sec with vmxnet3s