[illumos-gate] 16812 fsck_pcfs: need to support 4kn sector size -- Toomas Soome <tsoome⊙mc>

thanks to whoever fixed the problem that was keeping OmniOS from booting in XCP-ng.

I'm not sure what that would be

off the top of my head

XCPng was identifying itself as hyper-v

at least that's what I saw

although there is also a change related to it's emulated nvme support

it was the nvme support that was hosing me when I tried before.

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?

(I'm trying to figure out why iperf3 says the network speed is pathetic.)

dladm show-link

oh, no, not that one either

show-phys?

LINK MEDIA STATE SPEED DUPLEX DEVICE

e1000g0 Ethernet up 1000 full e1000g0

VM? or a physical e1000g interface?

VM

what hypervisor?

and what I'm seeing is a Linux (AlmaLinux 9) VM on the same hypervisor is getting multiple orders of magnitude better results.

XCP-ng

doesn't it support virtif?

jbk, the "NIC type" options are e1000 or RTL8139.

Is virtif something I need to set in OmniOS?

I believe we have a para-virt 8139 driver

I just did a basic default install.

tho I have no idea about any kind of recent xen

richlowe, I get the same (bad) speed with either NIC type.

I just know that when we build i86hvm we build a separate PV 8139

that's the extent of my xen knowledge, unfortunately.

rmustacc: see, 8139, another cockroach nic.

tulip, 8139, 3c509?

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.

I think jbk meant vioif

virtio network interfaces

that would explain why I'm not finding it :)

err yeah

it's been a very long past 2 weeks :)

It's still Monday here.

A very Mondayish Monday.

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.

I didn't expect it to be 97.8 Mbits/sec though.

(All using exactly the same iperf3 command.)

(all VMs running on the same hypervisor)

nomad : all with the same network driver?

all with the e1000 device, yes.

e1000g is one of the drivers I would have bet on not being slower than necessary

given the sun systems it shipped in :\

I just installed this VM using a fresh download of OmniOS 151050. Everything was set to defaults.

(and yes, I did patch :)

but that doesn't mean this isn't a tuning problem.

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.

can someone confirm for me that the `findroot` test skips on x86 too? I think it's because `user=root` lacks the spaces, maybe?

richlowe, is this a test I can run for you? I'd need some context :)

it's one of the tests in the util-test suite, but I'd hoped someone had run it recently and could just look :)

it's going to be a couple hours before they all finish on (emulated) arm.

richlowe: it has a dependency on idmap

if [ $(svcs -H -o state svc:/system/idmap) != "online" ]; then

echo "svc:/system/idmap not enabled and online; can't do SID-to-UID mapping" >&2

exit 4

fi

the test is new with 16546

sommerfeld: thanks, I'll check if that's what's happening

for me, on x86, it will PASS if idmap is enabled, and SKIP if it's disabled.

it was that, it now flipped to FAIL, I'll look into that separately and assume it's aarch64 related

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)

I can take a look

might point towards which thing isn't working.

ah, it mostly worked, except for -sidacl which is the most complicated variant.

(it maps the sid to both a uid and a gid and looks for both in acl entries)

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.

it does everything in a temporary directory that should only have four entries (a b c d)

that is surprising, I'll run it with -x and look at it assuming it's a bug here.

what I especially don't understand is that I would imagine `find . ...` to always give output beginning ./

sommerfeld: the `/root` is the text from `cd -`, the 2nd find invocation found nothing.

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.

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

much better than mine, but still much slower than would be expected.

richlowe: ah, d'oh.

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..

idmap dump -v and ls -lnn may also be informative.

nomad: w/ e1000g or vmxnet3s?

jbk, he tested both. I'm working on a writeup now.

the 5.66 was with e1000

he got 28.5 Gbits/sec with vmxnet3s