copec: Debian12

the perfer is to run NVMoF, not NVMe over TCP; they had the testing data, the same environment, if the client to storage server by NVMoF, the 4k roand read/write, the P95 will be 2000k IOPS, if run with NVMe over TCP, it’s about 800k IOPS, if run with iSCSI, just only 600k IOPS

Cheers, I've read recently about some start-up using GPUs as soft-RAID cards (allegedly faster than other PCIe links), and wondered if there were any efforts about ZFS using video-cards? e.g. servers might have some on-board and practically un-used (especially if needed just for troubleshooting console once a year) but still somewhat decently spec'ed (because can't buy anything smaller). The GPU part might speed up e.g. crypto,

r RAM could be (L2?)ARC for example...

Did anyone propose or experiment with something of the sort? :)

As a separate question: is there a way to tell OI (or OO) to use a blinking cursor in text mode - when booting and later in login prompt or logged-in session? For context: DigitalOcean recovery consoles tend to disconnect when there is no activity for a minute, which is very annoying during troubleshooting sessions (waiting for kernel dumps, watching for rare console log messages, etc.) :) It was seen with other VMs that having

r blink provides enough traffic for the console to remain active indefinitely...

currently there is none, but ofc we can build a knob.

Any idea of illumos would run on Netra X4200 server? Someone's selling one of these locally for like 200 dollars

Possibly, but it ran really badly on the couple of X4200M2 systems I got rid of a couple of years ago

Those are really quite old now, although the whole generation were excellent workhorses at the time

jimklimov: i think the biggest issue would be finding GPUs such that we can actually use them from the OS (AMD might be better here than nvidia)

but openzfs has some support for non-GPU accelerators for stuff, though the way (at least last time i looked) they added support wasn't exactly what I'd call great

lots of 'if (have_accel) { do_this(); } else { do_this(); }' littered everywhere

basically

though maybe that's improved recently

jbk: Is there any reason it'd be bad to add a demangle-sys entry point that let me specify the final buffer to use given we just strdup the output?

i can't think of any -- IIRC (it's been a while) part of that awkwardness was more about trying to stay compatible with the existing sun studio libdemangle interface

OK, thanks.

but all of that should be treated as private interfaces, so i think we should be ok to make things as useful as we want (just a lot of the sgs stuff used it as well, so i suspect any incompatible changes would require touching all of them.. probably not a big deal in terms of difficulty as much as quantity)

It's fine. Just looking at this for libdtrace.

Hey all. We have a server with rge0 interface that has the IP address 1.1.1.1, it also has the IP address 10.0.0.1. We also have a zone that uses VNIC over rge0 and has the address 10.0.0.10, and we've configured RDR to point from 1.1.1.1/32 port 389 -> 10.0.0.10 port 389 tcp.

I can see via snoop that the packets DO arrive to rge0, but I can never see them arrive to the zone

any thoughts?

P.S. the 1.1.1.1 IP address was a placeholder for privacy... we're not that dumb :P

Do you have forwarding enabled?

Check the output of routeadm(8).

FUUUUUCKKKKKK

rmustacc that was it :)

rmustacc thank you <3

rmustacc on FreeBSD I always remember that... here I totally forgot to check, altho I knew.....

While it's frustrating, it's always nice when it's a simple thing.

[illumos-gate] 16033 MSRPC services using anonymous RPC sessions fail with NETWORK_ACCESS_DENIED -- Matt Barden <mbarden⊙rc>

would it ever make sense to enable ipnat with forwarding not enabled? maybe /lib/svc/method/ipfilter could check for that with a sensible error message. (one complication is that you can enable forwarding on an interface-by-interface basis, so getting the check right would be tricky..)

jbk if you have the binary I could run it on the omnios I have in oci

i do, just need to think of how to get it to you

I have network in the OCI vm, just dns is not working

I'm running OmniOS r151049 Version omnios-master-71f55ca7377 64-bit, is that relevant, should be latest bloody

[illumos-gate] 16238 First output with kbm_debug should say illumos -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 16227 ena: CQ tail pointer no longer supported -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 15405 Port NFSv41 base -- Vitaliy Gusev <gusev.vitaliy⊙gc>