can drop the trailing \

Heh,

Supercede has occurred as a spelling variant of supersede since the 17th century, and it is common in current published writing. It continues, however, to be widely regarded as an error.

https://www.merriam-webster.com/dictionary/supercede

huh, what do the existing tests do

Interesting point - ideally we'd be able to generate sparse files within a makefs-created image.

(sigh)

when ZFS grows the pool, it will add more metaslabs of this same size.

So we want to keep the number of slabs small, so that growing the pool to 100x the size doesn't result in 16,000 metaslabs.

The only downside is, any slack that doesn't fit into a metaslab will be unused, so if we just set a metaslab size of 4G, then we'd only have 8G usable from a 10G image.

Although without knowing how large they are going to grow it, it can be difficult to guess what number is right.

It was just something I did early on to make it easier to run tests, where I had a bunch of tests that didn't require any privileges (since I hadn't yet gotten to the point of successfully importing the generated pool). Dropped now, I just forgot to revert that bit.

Yeah, that's a future TODO. For now I could just have the tests write data from /dev/random or something. Maybe that'd be a bit too slow under qemu though, not sure yet.

Ahh, I thought that ZFS would potentially resize the metaslabs themselves. Apparently not. I'm not sure how best to handle this, given that OpenZFS itself doesn't seem to bother (at least based on the end of the comment in vdev_metaslab_set_size()).

It's not really possible to know which metaslab size is the "right" one, though. The tradeoffs involved also depend on whether certain optional features are enabled, like the log spacemap and spacemap histograms, I think. Right now, makefs' choice is too closely tied to the initial image size and will give excessively small metaslabs for most purposes. If our chosen metaslab size is large, we can also adjust the output image size to compensate based on the -m and -M parameters, so unused space isn't a major problem.

I'm inclined to keep it simple and do the following:

• let the metaslab size be 10% of the image size, up to 512MB
• add a -o msshift option to let the user override the heuristic

That'll give basically the same size as OpenZFS for images expanded to up to 100GB. Beyond that, the answer might just be to create a separate pool if you really need a larger metaslab size, or somehow teach OpenZFS to resize metaslabs if it can determine that it'd be profitable to do so.

We might want to update the WITHOUT_ZFS description also - it includes "libraries and user commands" now, but doesn't reference ZFS support in tools that are not exclusively ZFS.

Although now that I look at it, stand doesn't use MK_ZFS at all right now, but probably should? A separate issue in any case.

In most of the Makefiles, it's spelled MK_LOADER_ZFS because it's traditionally been decoupled from the host for a number of reasons, not least in that not all loaders support ZFS. There's not a good, general mechanism for a lot of these loader variables. I did a lot of cleanup when I imported lua (I retired a lot of accumulated technical debt, but we have a long ways to go still). Detangling it would be more than just including MK_ZFS somewhere, I'd think.

Hmm, maybe this should be spelled MK_CDDL (as in libprocstat) instead. The makefs code itself is BSD-licensed but makes use of the CDDL-licensed zfsimpl.h.

Downstream we changed that to MK_ZFS so we could turn it off for CHERI as ZFS has not been ported, and MK_ZFS makes more sense to me there. ZFS is CDDL-licensed but gets its own knob, so why should using bits of ZFS elsewhere not use the same knob just because they're CDDL-licensed? Turning off CDDL implies turning off (LOADER_)ZFS anyway.

That makes sense to me. All of the other WITHOUT_CDDL uses are related to DTrace.

src.conf.5 update for WITHOUT_ZFS: https://reviews.freebsd.org/D35337

If there's no objection to changing the option for libprocstat, I can do that.

Ah, I see. It seems the same could apply here since we can have ZFS support in makefs regardless of whether we have kernel / userland support, but not really a practical concern.

Curious about this - just to avoid issues from simultaneous test execution? (Is this one case where $$ might actually be a good option?)

Yeah, $$ could be used here.

The randomized name ensures that tests can be executed simultaneously. I was also a bit paranoid about colliding with an existing pool, even though it's already quite unlikely that anyone has a pool called "makefstest"...