Is there anyone working on fenix illumos#17572 ?

BUG 17572: mdb should use CTF for `struct module` (In Progress)

↳ illumos.org/issues/17572

I started looking at it a couple of weeks ago and ran into a chicken-and-egg problem with the module loading code. I need to get back to it and see what's possible.

The "struct module" bits added in 17467 should have been at the end of the struct it turns out :(

I tested mdb extensively in the post-17467 world, but not with dumps from before and vice versa.

Eesh.

I took a cursory peek, and I'm going to guess it's not as simple as merely making `kt_load_modules` aware of before-and-after the kobj.h ?

Ahhh... yeah, a git grep has confirmed it certainly is not.

Lots of places can be converted to CTF, or they're in KMDB so there's no issue.

That module loader is the biggest headache.

I'll get back to looking at it, and sorry for the inconvenience!

I can workaround it w/o issue, but if/when it's ready I have some test cases ready to go!

just to ask... i'm guessing running 'rm *' on a directory with multiple millions of files is likely to choke (by virtue of trying to glob that many files)

and (assuming no subdirs) 'find . | xargs -n 100 rm' or such is probably going to be a better approach...

"rm -rf ." ?

I'm pretty sure that immediately fails, or I'm misremembering some funny story about POSIX compliance

jbk - yes, I'd just `rm -rf <dir> && mkdir <dir>` or `find <dir> -exec rm {} +`

and next time I'd likely just make it a zfs dataset with an empty snapshot - `zfs rollback <dataset>@empty`

yeah.. there are definitely better ways to structure this... but it's what's there now

if nothing else, i'd imagine even though (IIRC) directories are stored as btrees on disk with zfs, it's probably still not exactly tuned for such large sizes

directories are ZAP objects. So it depends on the size if they are micro or fat zap objects.

given the number of entries, i'm going to assume it's a morbidly obese zap object

;)

if I remember, joyent had _way too many_ files in ZFS directories

which is why they had to implement `ls -U`

someone from that era may have facts

it was more I believe that some customers had too many files in a zfs directory (though maybe early versions of manta didn't split things up more)

and since ls has to read the entire contents of the directory in order to sort them (without -U), it could consume a lot of memory

if ls was a bit smarter and more efficient, it might be able to mitigate _some_ of that (the entry struct it uses isn't optimal, and it could in theory in certain circumstances do things like only call stat(2) as needed and keep the results local to the call instead of stashing them, etc.

but it would never completely eliminate everything

Is there an easy way to find out "zfs get <something> <a-dataset>" in a kernel panic?

Hell, is there a hard way?

yes, zfs get reads properties, so you can find *prop* from stacks

I may be asking this wrongly. I have a kernel dump, I cannot, with existing dcmds, get "zfs get <something> <a-dataset>".

"zfs get" reads properties, but I don't have any "zfs " programs running amongst the processes in this dump.

Not unless it happens to be a cached property.

I don't know if there are dcmds that do have a way of looking at that off hand unfortunately.

Me neither. Thanks. Gotta run, unfortunately.

if you were to implement one, that would be very nice