In D31707#715576, @bcr wrote:

That's right. My understanding is that everything is a dataset unless it was created by "zfs create -V ...", which for me is a volume (and used in this way). As you said, it may change or even blur some more with future changes. My idea is to use them consistently, for example mention datasets everywhere when it comes to ZFS features. When involving mountpoints, I'd refer to file systems, like this: "Mount the dataset as a file system into the directory tree." That way, we use it only when necessary, but keep the dataset syntax. Same when it involves volumes.

A few comments, mostly agreeing with the suggestion.

Another fine set of changes, including most (if not all) suggestions by @pauamma_gundo.com

In D31707#715615, @debdrup wrote:

In D31707#715576, @bcr wrote:

Maybe one more reason to use dataset more to avoid this ambiguity? ;-)

Calling them datasets introduces new ambiguities, because a dataset can both be a filesystem and a volume, and it's possible that it's definition will be expanded in future versions too.

Second installment. (Let me know if I'm too nitpicky or overwhelming.)

In D31707#715576, @bcr wrote:

Maybe one more reason to use dataset more to avoid this ambiguity? ;-)

Update diff to incorporate changes from @debdrup and @pauamma_gundo.com . Looking forward to the second half of changes. I know it's tedious and I should have kept it shorter. Will consider than for future changes like this on other chapters.

Thanks for your suggestions, @debdrup and @pauamma_gundo.com . I incorporated a lot of them into the next set of changes.
I looked at our current docs for the word list on how to write "file system" versus "filesystem". It seems like it does not exist in the FDP primer anymore. It used to be there in the old one: https://www-legacy.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/writing-style-word-list.html . Maybe one more reason to use dataset more to avoid this ambiguity? ;-)

Past 80 comments and I'm losing focus. Submitting what I have, will continue later.

These are a few things I spotted, but I'm not sure I caught everything and I'm on the wrong side of entirely sober. :)

Updated diff incorporating suggestions by @ceri

In D31707#715385, @ceri wrote:

Running out of battery so submitting what I have reviewed. Generally speaking I think the shorter text works against the intent of this being a guide, I'm afraid.

Running out of battery so submitting what I have reviewed. Generally speaking I think the shorter text works against the intent of this being a guide, I'm afraid.

This one uses git diff --no-prefix -U1000

Can you switch this diff to one with context? It makes it easier to make suggestions. :)

I always have to ask sjg. Maybe add him to the review?

This looks good to me. I recall that Makefile.depend will be generated by whoever needs it and does not need to be committed if you aren't sure how to do it, but I don't see that in the committer's guide so I'm not sure where that idea came from. Hopefully someone else has input on that aspect.

atomic.S patch by mav

I am in for the assembler code patch. I will prepare an updated version.

Actually my original version was written in assembler to be added into atomic.S without using the compiler atomics: https://people.freebsd.org/~mav/zzz3S.patch . I think it would be more consistent with original code. But since it is hopefully temporary, I am fine with any approach.

I am definitely going to do that. But in the meantime we need a buildable stable/13 for i386. The solution I am proposing does (temporarily) place an additional file into cddl/lib/libspl what is outside of sys/contrib/openzfs.

Could you ask him to merge the dependency instead of creating unneeded divergence, unless there is a good cause?

I assume Brian just forgot to merge that commit or intentionally didn't merge that commit and did not inspect your commit for changes in that direction. The i386 build should be broken for Linux as well.

Aaa... While the patch may be OK, I am surprised that my e76373de7b7384bb6e5c6fd5e04f15b54df20fb7 was merged into zfs-2.1-release before fef8bd41fc178d7212957b611c9bc81fe10cb63e. Merge in proper order would not cause this problem in first place. Do you have a clue why it was not done that way?

Thank you for catching this. The version strings look reasonable to me.

I've been able to keep a NO_CLEAN tree going for several years; it does break occasionally but we have a standard, if ugly, way of addressing the resulting dependency issues when they occur.

I will apply your patch, but it's a bit silly to call that "breaking world". -There's no guarantee that -DNO_CLEAN or -DNO_KERNELCLEAN will work across major changes.

Yes.

@neel_neelc.org was this a -DNO_CLEAN build?

looks good to me.

This is the error I get without the patch:

This patch fixes the build issue complaining about:

@neel_neelc.org can you tell me a bit more about your environment, make universe builds for all of us and only the powerpcspe tinderbox is currently broken because of these changes. I'm happy to commit these changes I just want to know what it's fixing.

In D19094#443654, @avg wrote:

Sorry, I myself went missing for a long while.
Yes, I can commit this change.

Do you want anything specific to appear in a commit message?
Like any additional attributions, etc?

Sorry, I myself went missing for a long while.
Yes, I can commit this change.

In D19094#418092, @avg wrote:

In D19094#417188, @slw_zxy.spb.ru wrote:

No more replays?

Unfortunately, no.
I think that we can commit your proposed change. If George comes up with a different and better solution later on, there should be no problem switching to it.

In D19094#417188, @slw_zxy.spb.ru wrote:

No more replays?

In D19094#412736, @avg wrote:

In D19094#411932, @slw_zxy.spb.ru wrote:

Do you succesefull contact George?

I've just got a reply from George.
He agrees with your analysis, but needs some more time to think about how to address the issue.
Let's wait a bit more.
Thanks!

In D19094#411932, @slw_zxy.spb.ru wrote:

Do you succesefull contact George?

In D19094#410508, @avg wrote:

Let me try to contact George again.

Let me try to contact George again.

In D19094#410239, @mav wrote:

In D19094#410192, @slw_zxy.spb.ru wrote:

Don't sure about calling remove_reference() from arc_hdr_alloc_pabd() (or from parallel tasks), but see at ARC MFU/MRU size calculation in arc_change_state() called from arc_access() and !GHOST_STATE(state) case in arc_get_data_impl() called from arc_hdr_alloc_pabd().
I mean interchange this lines can cause problems for this accountings.

I am not sure what accounting problem you are talking about,

In D19094#410192, @slw_zxy.spb.ru wrote:

Don't sure about calling remove_reference() from arc_hdr_alloc_pabd() (or from parallel tasks), but see at ARC MFU/MRU size calculation in arc_change_state() called from arc_access() and !GHOST_STATE(state) case in arc_get_data_impl() called from arc_hdr_alloc_pabd().
I mean interchange this lines can cause problems for this accountings.

In D19094#410062, @mav wrote:

While I see the problem you are fixing, the fix looks ugly to me, that is why I would look for something nicer.

In D19094#410076, @lev wrote:

Huh? As far as I can see, problem not remove_reference(), but arc_adapt() called too late, with header in wrong state (promoted from something-ghost to live LRU), which brraks main idea of ARC adaptation.

In D19094#410062, @mav wrote:

While I see the problem you are fixing, the fix looks ugly to me, that is why I would look for something nicer. I agree that according to logic of remove_reference() dropping last reference for header in ghost state is a failure, but how can remove_reference() be called before the arc_access() just on following line? I would guess from description telling about the case of prefetch read it should happen no sooner then we actually initiate the I/O, which is done much later then those two lines. So while I agree it is somewhat odd to have buffer for header in ghost state, is that a criminal.

While I see the problem you are fixing, the fix looks ugly to me, that is why I would look for something nicer. I agree that according to logic of remove_reference() dropping last reference for header in ghost state is a failure, but how can remove_reference() be called before the arc_access() just on following line? I would guess from description telling about the case of prefetch read it should happen no sooner then we actually initiate the I/O, which is done much later then those two lines. So while I agree it is somewhat odd to have buffer for header in ghost state, is that a criminal.

Thank you for the additions! Just my $0.05 worth of nit picks post commit.

Update the diff based on Allan's comments. I've decided to remove the newsyslog compression example. This might be something better suited for the handbook. In it's place, I've added Allan's zfs snapshot range deletion examples. I've also changed the date in the custom property example to a more prominent date. ;-)

Thanks for your feedback, @allanjude. I'll work on an updated patch that incorporates it.

Adding more reviewers for more pairs of eyes for eventual approval.

Update with suggestions by Dru.

These look great!