okay, spent a bunch of time with the sonic tech and got their NOC to agree that the way I have the switch connected between router and ONT is not going to cause trouble (he also fixed the fiber run to match what the original installer should have done).

(and then retrieved our main car from the shop where they spent 3 days determining that it needs to go to the dealer for warranty service)

3 days?!

after my vehicle was stolen, it was something like 8-10 weeks since they had cut a wiring harness which messed up the backup camera

and the dealership was never able to fix it 100%

tsoome_: brought it in Monday; they thought they figured out what parts they needed (fuel injectors) and ordered them; they got them Tuesday, tried to install them and discovered they were bad. while recovering from that they double-checked the TSB they were working under and discovered it had been superceded by a new one which said that Honda will fix the problem under warranty....

ou. I see...

I am now creating a scenairo, where a disk falls out from a zpool mirror. So I have created to file, representing the 2 disks. Then I have created a zpool using them, specifying "mirror" and mounted it under a specific folder. Then I have attempted to create an important file the following way:

dd if=/dev/random of=/gyak/fontos bs=1M count=10

I have expected a 10 Mb file to be created, but to my surprise it created a 10KB file

It turns out, somehow the /dev/random messes things up, as the command works ok and created a 10MB file if I use /dev/zero

root@omnios:/# dd if=/dev/random of=/test/important bs=1M count=10

10400 bytes (10 KiB) transferred in 0.103425 secs (98 KiB/sec)

root@omnios:/# dd if=/dev/zero of=/test/important bs=1M count=10

10485760 bytes (10 MiB) transferred in 0.002303 secs (4.2 GiB/sec)

Also it seems the RNG throughput is pretty low. Is this som

is this something to be worried about?

oh, I guess the illumos man page for /dev/random doesn't have this bit that's in the Solaris version:

The limitation per read for /dev/random is 1040 bytes. The limit for

/dev/urandom is (128 * 1040).

but also, unless you're generating cryptographic keys or such, you probably want to use /dev/urandom instead of /dev/random anyway

short lived keys are better from /dev/urandom

szilard: /dev/random is for high value random data.

There is a cogent argument for getting rid of high-quality /dev/random outright. One of the BSDs (Free?) did just thank, linking {.u}random as one.

I'm not 100% convinced but it is a thing, and sommerfeld details why I'm not 100% convinced.

danmcd: or at least hiding it better

^^^

if it was named /dev/veryslowrandom we wouldn't have this problem

I wonder if `crandom` (Cryptographic-random) would work? single-letters probably not a great idea?

If a good accepted name comes up, the plan could be new-name up, `random` eventually switches from slow to fast once you're convinced enough apps who need the good stuff know its new home.

rmustacc: i think i forgot if you answered this before, is there a topo mod that should enumerate slots for hot pluggable NVMe disks? (if so, which one?)

or does that require a map for the system?

(at some point I'd like to document all of this so people can create maps for their systems if they want)

so I discovered a bit of a gotcha this morning: illumos.org/issues/17486

→ BUG 17486: dhcpagent gets stuck sending to igc link that's down (New)

there is a behavioral difference between e1000g and igc; if you transmit something on igc when the link is down, it still ends up occupying a tx ring slot.

e1000g uses a different tx interface and explicitly has code to free the packet immediately if the link is down.

I'm still wrapping my head around our diversity of tx paths.

(bigger picture here is that backpressure works its way back through IP to the socket and dhcpagent's sendmsg blocks, stalling DHCP on all interfaces, not just the one that's unplugged)

does illumos not gitignore *~ on purpose?

(I noticed it didn't ignore .#* which is sort of the same thing, and went hunting)

I can only give you a "no idea" response. I'd expect it to be a good candidate for the top level .gitignore

.# might be good unignored as lock files suggest you weren't as done as you thougt, I suppose

sommerfeld: one of my pet projects (to at least proof of concept) is something akin to iflib on fbsd where a lot of the DMA buffer managment + translating of mblk_t<->DMA buffers can be done in one place (on an per driver opt-in basis)

since it seems like that accounts for a pretty decent amount of the potential complexity in a lot of drivers

(as well as potential sources of _significant_ kernel memory usage)

one of the other fun bits is vnics + jumbo frames with many NICs

(watch as the VM system gasps for physically contiguous RAM :P)

@richlowe I thought emacs didn't create *~ files while inside a git repo? My emacs doesn't.

[illumos-gate] 17441 isnsadm does not build with libxml2 2.14 -- Andy Fiddaman <illumos⊙fn>

danmcd: the file I was hunting was a .# lock, I noticed in the process we didn't ignore other similar things

Ah.

we don't do vim swp either

that I can find

anyway, I thought because the full set seemed missing perhaps there was a reason

I like seeing vim swp as noise... tells me I'm doing something local.

see above re: "not as done as you thought"

:)

jbk: anyhow (as I noted in my bug an hour ago) i40e does a freemsg() in its _ring_tx function if the link isn't transmitting, and igc doesn't.