hrm...

rmustacc: the mac ring tx entry point takes a _chain_ of mblk_ts, correct (i.e. it could be more than 1 packet, and of course each packet can itself be segmented)

?

the man page says yes, but looking at i40e's i40e_ring_tx -- unless I'm missing something, if passed a chain of mblk_ts, it looks like it only sends the 1st one

it's late, and I wasn't feeling great the past two days, so I feel like I'm maybe missing something obvious

jbk: The reality is that mac is only giving the mri_tx entry point single mblk_t's with no b_next. But I don't think it should long term.

ahh ok

But I realize that the docs aren't as good there so it leading to confusion doesn't help.

I think at one point I accidentally wrote some wishful thinking into some of the drafts and then after they sat there for a while I forgot about that.

But for now you can just ASSERT that b_next is NULL.

Which nic is this for again?

we need a working ice NIC (since some of the HW has it built-in), so I _just_ started with the work you did (really just looking over things closely as well as teh programming guide so far)

err some of the HW we want to support

OK. Main thing I wanted to mention there is that the I/O engine is identical to i40e.

yeah

So you can more or less use it verbatim, especially for the issues around TSO.

which reminds me, i need to upstream my changes there -- basically caps the DMA buffer size for data at 2k and trades off more descriptors for smaller buffers (and yeah, the TSO bits were annoying getting that right)

i think some smartos people ahve seen it as well where jumbo frames can cause _long_ vnic creation times

(in terms of minutes.. I think we saw one where the dladm command was blocked for > 30 mins :P)

Requiring contiguous buffers is never great, just was a simplifying approach when I did this a long time ago.

yeah

get it working, then get fancy

i still need to finish writing up an IPD -- I think we could (opt-in) have mac handle a lot of that for a driver and just hand off (more or less) an array of (paddr, len) + flags (I'm simplifying a bit) to transmit... (i've prototyped a bit where not opting in shouldn't see anything different aside from like 2 extra if ()s in mac

just to try to contain any potential blast radius

[illumos-gate] 15657 struct pam_message in conversation function should be const -- Dominik Hassler <hadfl⊙oo>

The devil is in the details so I'll be curious to see what you come up with and what parts you're trying to hand off.

Hello, coming here for some help. I have NVIDIA GT 1030. The latest driver is 550.100, but the NVIDIA driver search on their website gives me version 387.34 to download. Which one should I install? Thank you.

Hi, is any way to run gdb to debug a proccess inside LX zone? It complainer about "Couldn't write registers: Input/output error"

Also gdb complained "warning: opening /proc/self/mem file failed: Read-only file system (30)"

In dmesg in global zone: "attempt to execute non-executable data at 0x7fffecc10000 by uid 0"

That's presumably with the Linux gdb? There's also the native illumos gdb which, if installed in the global zone, will be at /native/usr/bin/gdb

Although the native gdb might have as much trouble understanding a Linux process as the Linux gdb has understanding running on an illumos kernel

ptribble: Linux gdb in LX zone.

Yeah, I suspect the ptrace and related emulation is going to be fairly minimal.

Xaero, what do you need that gpu for on oi?

Wait, do people run games in Linux zones?

i game on a windows disk

but i use the same gpu on OI

Hmmm so people don’t game much on oi?

I’m sure many foss games would work on it? Sdl2 work I assume?

How to remove zfs from a device?

blue-cat: The simplest way is usually just 'zpool destroy', but specifics will vary based upon data.

That is how you want the data to be removed.

i'm sorry, i had a little connection problems and was disconnected

a few times, and i haven't seen any messages

blue-cat: you can see the logs at log.omnios.org/illumos :)

zpool destroy?

i probably can't do it from running os, but i can do it from usb

?

blue-cat: there's also 'zpool labelclear'

if you have multiple pools, you can safely 'zpool destroy' the pools that don't have the currently running root filesystem in it (but you might first have to kill off processes that have stuff open/active on the filesystems to allow them to be unmounted).in th

oh, ooops, blue-cat left before i responded.

sommerfeld, sorry, i have unstable connection

but i still can read the logs, as i've been instructed to do

do i need to `zpool destroy` first if i `zpool labelclear`?

blue-cat: or 'zpool export'

as rmustacc said above, the best command for this it depends on what you're trying to accomplish.

are you trying to render the contents of the former pool completely inaccessible, or do you just want it not marked as containing a pool in a way that might confuse a future 'zpool import' ?

"how to remove zfs from a device?" was my question

right, what exactly do you mean by that?

im not sure

what is the presence of a zfs pool on a particular device or set of devices preventing you from doing?

we've had problems that people don't seem to find easy to repeat with growing zfs pools where the device has a end-of-pool label lingering on it

in that case, labelclear does the job, I believe.

for instance, if you're trying to render the former contents of the pool unrecoverable, "zpool destroy" alone won't cut it (see "zpool import -D" which can bring back a destroyed pool)

that's the only "remove zfs" case I know of where something really does need to happen.

i just want to know how to remove it

if you want reliable destruction, use encryption and forget the key

the lightest weight way to get rid of a pool is "zpool export" (unmounts it, causes it to not be mounted on boot); that can be un-done by "zpool import".

"zpool destroy" is "export, and mark as destroyed", and it can be un-done with "zpool import -D".

potentially undone, as long as you don't do anything else in the meantime

"zpool labelclear" will destroy your labels, you won't be able to get the pool back after that, but a lot of data is still on the disk and readable.

zpool destroy or zpool export followed by zpool labelclear on the component devices should make re-import impossible (but the bulk of the pool contents could potentially be recovered forensically with a lot of work).

If you want to completely delete all data on the host you can use DBAN and wipe the drives. That might be a bit of overkill,depending on what you need.

i'm just completely clueless, but my original question is still "how to remove zfs from a device?". all i know is that zfs is a filesystem. then a close question would be "how to remove filesystem from a device?". in linux, such questions are usually answered with "use wipefs".

But as far as I know zpool labelclear -f does more than wipefs with zfs

what do you mean by 'remove' and by 'device'? What do you want to do with the device (I presume a hard drive, SSD, or equivalent)? If you just want to reuse the drive with a different filesystem then blow away the partition table, repartition it, and on you go.

A very quick read of wipefs(8) manpage looks like wipefs just removes the partition information by default.

yeah, but people say wipefs is not enough for zfs

its why i am asking

I mean if you want to be absolutely sure

you can write zeroes to the whole disk

Mind you, that's still not a "secure" erase

But it will at least be casually gone

the best-in-class approach I believe is still to use ZFS encryption and forget the key

but not an after-the-fact thing

If it's an NVMe disk, you can "nvmeadm secure-erase" probably

its not nvme and fill with zeroes is so long

Is the goal here secure disposal? i.e., you want to throw the disk in a rubbish bin and not have someone recover the contents

if it's a hard drive and you want to securely erase it use DBAN (Derek's Boot and Nuke). That won't work on SSDs or such, though.

if the goal is secure disposal, you can also go rent a hammer drill

and some goggles

thermite!

just some linux distributions advise something like `wipefs -a /dev/sda` before installation

This is why we keep asking what you want to achieve.

We're just guessing at what you actually need because you haven't explained your use case.

i can't remember exactly, but one of them is chimera linux chimera-linux.org/docs/installation/partitioning

im not sure why they do this

because sometimes installers see an already formatted disk and think they can't use it.

but after googling i found that wipefs does not erase zfs properly

but *for that use case* blowing away the partition table (which is what that wipefs command does) is sufficient.

installers also can wrongly use already formatted disk and throw error

blue-cat, it looks like you're ignoring what I'm saying so I'm just going to say this then go back to work: Try It. Don't just believe what you read on google. If your reinstall fails because it can't find a usable drive *then* try to fix the problem.

okay, you said just create new (gpt) disklabel?

blue-cat: sure, just create a new partition table (gpt)