In D35336#801073, @markj wrote:

One other thing that might be useful is a script to enable some or all feature flags on a pool. The WIP makefs -t zfs implementation leaves all feature flags off.

One other thing that might be useful is a script to enable some or all feature flags on a pool. The WIP makefs -t zfs implementation leaves all feature flags off.

In D34426#801064, @markj wrote:

Use makefs -t zfs instead of zpool(8)/zfs(8) to create a pool and datasets.

This eliminates a number of problems with the old approach:

• images will be reproducible
• no need to import any pools on the host
• no special privileges are needed

I had read 'initial address of zero' as meaning that the first iovec had iov_base of 0. Saying something like "the first vector" probably is a bit less ambiguous.

In D35336#801061, @asomers wrote:

Will you create a matching change that will run zpool online -e on firstboot, or just assume that the VM images will be built with autoexpand=true?

Use makefs -t zfs instead of zpool(8)/zfs(8) to create a pool and datasets.

This is going to be very useful. Will you create a matching change that will run zpool online -e on firstboot, or just assume that the VM images will be built with autoexpand=true?

It is quite an old patch, but yes, I have patches from a long time ago that use TPR for spin locks. I will see if I can forward port them into a branch.

Ok, sounds good. When those changes get merged to src main, the commit in src main to add these warning suppressions should be reverted as well.

Implement suggested rename of variable

Rebase over d59bc188d652dfaa06bef9963120aa54c4c68875

Add assertion befor vput().

In D35331#800920, @dteske wrote:

Do you need me to commit this or do you have a venue/access?

In D35326#800927, @imp wrote:

In D35326#800926, @rpokala wrote:

In D35326#800921, @imp wrote:

"You should not use glabel with any device you plan on putting a filesystem on"

might be better advise.

Huh? Did you mean "If glabel is used, the filesystem should be put on the glabel device, rather than both label and filesystem put on a the same underlying device."

(Or are you commenting on the quality or usefulness of glabel?)

I was being catty.... But your advise is much better. glabel steals a sector or two for it's labeling info, and so you need to use the glabel device. It's also why you can't usually label something after the filesystem is on there: these stolen sector will be fought over potentially.

Try to address the review feedback

Thank you for addressing all the feedback & adding tests!
I added a couple of more comments - should be the last round prior committing the feature.

• Add the lltable.llt_flags member and LLT_ADDEDPROXY flag in it
• Add lltable_flags_free() that frees LLEs with specified la_flags
• Use lltable_flags_free() for freeing in6_multis in if_detach path
• Add the test script

mdoc(7) syntax looks good to me, so once the other issues pointed out with the manual page have been fixed, I'm happy to accept it.

All review comments have been addressed. LGTM.