Approved: however since this depend on the 64 bit inode changes, my guess is that it cannot be merged to stable as-is.

In D11530#284219, @fsu wrote:

What I find confusing is that there is "force_64bit_alloc", labelled for testing/debugging only and a couple of TODO things that give the impresion that the implementation is still not ready.

Yep, seems like I should ask the suggestion here...
Let me explain. This is hack to allow to allocate blocks outside of UINT_MAX range, which was used for testing purposes..
I mean, it is too difficult to test 16TB volume in case of ENOSPC without it.
So, I want to store it in svn history, to explain, how it was tested.
My plan was to commit main patch and then remove this hack. Or it is too dirty behavior to store stuff like this in the history?

In D11530#284091, @fsu wrote:

I can confirm that it is ready to commit to head with long MFC for additional testing.
I made normal tests using fsx/fstorture + tests for modes when blocks are allocated out of UINT_MAX range.
More detailed information could be found in second test scripts attachment.
The reason why it was done in two phases (I mean a bunch of time between first and second review revisions),
because this feature heavily related with extents.
There were two ways to integrate extents and 64bit:

• RO extents, then RO 64bit, then RW extents, then RW 64bit.
• RO extents, then RW extetns, then RW 64bit.

So, the second way was chosen, because I decided, that it is more difficult to test RO feature implementation, than RW.
The next required feature is metadata_csum. When it will be integrated, it will be possible to switch to meta_bg/flex_bg features set.

What is the status .. is this ready or just an update for the record?

LGTM

Please add a description here to have an idea what the commit log would look like.

Cosmetic changes don't need to be in the Differential Review: they just distract us from the main changes.
Send me a diff privately and I will approve them.

In D13369#280781, @danfe wrote:

In D13369#280775, @eadler wrote:

In D13369#280745, @pfg wrote:

The next question is ... do we want this?

IMHO yes.

I still think that bringing in such amount of code for an otherwise unsupported filesystem is premature. As it was said, we can (and should) keep it in code review until the time comes when it's more useful.

In D13369#280752, @danfe wrote:

In D13369#280745, @pfg wrote:

The logical question is if it works at all. The next question is ... do we want this?

This is the main thing I was wondering about when I saw this DR. Do we ever plan to have this Hammer thing support, like being able to mount their volumes? What is possible usage scenario of this code in FreeBSD right now, without actual mount support? I fear that this code won't be maintained well and might start to bitrot since day one.

Interesting ...
I took the C files from DragonfLyBSD as well: I only changed them so that they would compile with the headers placed locally.
The style issues should probably be reported upstream, it is not something we should be fixing..
The logical question is if it works at all. The next question is ... do we want this?

For the record: Approved by mentor as well ...

Perhaps Eitan is interested ...

In D13369#279103, @bcr wrote:

At the top of fstyp.8, you need to bump the .Dd to the date of the commit, since this is a content change.

I have no time currently but as a side note there are at least a couple of interesting cleanups in OpenBSD:

In D13209#276906, @cem wrote:

Thanks!

If someone wanted to test this, how would they setup a test environment? Where is the mentioned test script? (Maybe I'm just missing it.)

Add kib and rwatson: this is not area really my area.

In D13209#275338, @thisisadrgreenthumb_gmail.com wrote:

LGTM, but I'll add some reviewers that may have further insight.