Fix copy/pasto that broke the build.

In D13133#273041, @imp wrote:

I spot checked about a dozen of these. I see no issues.

One thing that I worry about the crazy files that have 2 or 3 different licenses...

I know this change is too big for a review but given that the BSD 4 Clause license is considered problematic for some it is rather good to have some reference on where it currently applies.

In D12631#272110, @kevans wrote:

Can we come to a consensus on this, before I re-commit? @antoine has fixed up the non-applicable patches in the ports tree, so those should not be an issue any longer. I go back and forth on how much damage might have been done; other BSDs seem to also have this same behavior, but GNU patch will not let these patches be mis-applied as we do.

In D12631#270553, @cem wrote:

I think we should consider just fixing the bad patches, then re-applying this change.

As seen in the exp-run, there are patches out there that will break for this case.
I think we should skip the check when the -f, --force flag is specified.
Perhaps just changing the check to:

if (!force && pline > pat_lines)

will do the trick.

In D13015#270408, @kib wrote:

In D13015#270406, @pfg wrote:

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

Perhaps we should at least clean the lint cruft from sys/sys/cdefs.h

I specifically mentioned this in the explanation. I do not want to touch this now, and limited cleanup might be done later. I only want to remove the lint itself and lint libraries build as the first step.

This is all fine and well but we still also have a bunch of
#if defined(lint)
all over the tree

In D12631#267078, @kevans wrote:

Yeah, but that one's going to take a little bit of time, unfortunately. We currently have no tests for patch(1) at all, so I've got it on a list somewhere to write a bunch of patch(1) tests and include this as well as the other bug I recently fixed.

To Fedor: we need to setup a tinderbox build in the "universe" machines to catch things like this before committing.

FWIW, I sent benno some typo fixes long ago but I never heard from him (I'll dig up the patches again) ... the upstream email address is no more.

Upstream indeed seems to have disappeared but Benno Rice may know better.

I will be AFK starting tomorrow ... looks good to me.

Looks reasonable .. thanks!

In D12485#260056, @thisisadrgreenthumb_gmail.com wrote:

• remove extattr namespaces sysctl.

In D12485#259923, @cem wrote:

In D12485#259922, @pfg wrote:

I will be glad to approve the next iteration of this patch.

FWIW, I haven't reviewed fuse_xattrlist_convert at all because it looks "complicated" and still have hesitations about doing it in-place

In D12485#259905, @cem wrote:

Changes from v2 to v3 look mostly good!

In D12485#259853, @pfg wrote:

The problem I see with the sysctl is that we have too many of them; they are generally undocumented, and it's ultimately unlikely people will spend time on it. A default value ("fusefs" perhaps?) would be good to have.

I think the main problem is it configures globally a setting that is most useful per mount. But maybe I am overestimating the number of FUSE mounts people have.

Add cem@, he may want to review it before it lands.

Thanks cem@ for the review.

Related good news: thanks to mandree@ , the sysutils/e2fsprogs now has a FUSEFS option to build the fuse support.

This looks good to me.

Minor tab/space issues but otherwise looks fine. Thanks!

Recent changes cause breakage in lib/libthr/thread/thr_workq.c:

Bring up to date with latest head.

Such files only make sense in filesystems bigger than ext2/3. so of course, this only makes sense as preparation for ext4 write support.

In D12087#251589, @thisisadrgreenthumb_gmail.com wrote:

Ok, I am not sure that it is possible to overflow this variable.
We have 16 bit from e2di_nblock_high and 32 bit from e2di_nblock.
So:
pow(2, 48) * 512 / pow(1024,4) = 131072
Where result is in TBs.
The we can see from https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout (File System Maximums table)
That for 64k blocks in both 32bit and 64bit cases we have maximum file size 256TB.

As I can see on linux there is the next logic:
if (i_blocks <= 0xffffffffffffULL) {

		/*
		 * i_blocks can be represented in a 48 bit variable
		 * as multiple of 512 bytes
		 */
		...

} else {
... - use blocks
}

In D12087#251428, @thisisadrgreenthumb_gmail.com wrote:

In D12087#251372, @pfg wrote:

I might have missed it, but have you considered the case that requires writing EXT4_HUGE_FILEs?

Yep, you can see it from attached test script, the mkfs option -O huge_file was added in all cases.

I might have missed it, but have you considered the case that requires writing EXT4_HUGE_FILEs?

Very interesting feature. Small knits for now. Thanks!

Committed revision 447973.

Update with some review from gerald@

In D11530#245279, @thisisadrgreenthumb_gmail.com wrote:

Sorry for long delay from my side, but, seems like, this review revision should be frozen. It contain some "fundamental" problems, which can not be resolved directly. I found it, when started to play with large zvols. So, I need some time, and I can not estimate it for now.

ping @kevlo: any comments?

In D3848#242303, @kib wrote:

...

pfg, do not waste your time on this.

In D3848#242231, @lattera-gmail.com wrote:

In D3848#242229, @pfg wrote:

In D3848#242083, @jlh wrote:

I think stack protection has already been disabled in the very low level stuff. This change is fairly non-intrusive and I think he ready for further testing. Go ahead and commit please.

There are too many assumptions in the above statements. Oliver, have you tested this? I have only done very light testing so I don't want to assume responsibility.

Also, let me cc kib@ since this may end up affecting rtld.

Would you like me to do a ports exp-run with this patch applied next week with HardenedBSD's infrastructure? I'd be more than happy to.

In D3848#242083, @jlh wrote:

I think stack protection has already been disabled in the very low level stuff. This change is fairly non-intrusive and I think he ready for further testing. Go ahead and commit please.

Change according to feedback: instead of creating a -cgx part, only split away the ccx part. his is less confusing for end users and still attains our objective of constraining the fortran part in an independent port.
It also reduces the diffs.

I can't think of a better test for this than a tinderbox build.

In D11530#238833, @thisisadrgreenthumb_gmail.com wrote:

Ha...! The zfs with compressed zvol is good idea.

In D3848#238514, @jlh wrote:

Any update?

In D11530#238821, @thisisadrgreenthumb_gmail.com wrote:

In D11530#238803, @pfg wrote:

You can use the existing ext4gd fields but for the others we need to have extra care.

I think/suspect the 64BIT flag needs a 64 bit system and basically breaks the on-disk compatibility: I recall it was causing issues with some bootloaders.

The feature, just called 64bit, but, as I told, it is does not related to base types sizes, it is only about increasing size of struct ext2_gd, to add additional fields. Could you please describe about bootloadres? Do you mean, that FreeBSD ext2fs uses to mount boot volume somewhere?

To be able to test the patch for real you need a huge (>16T) filesystem. IMHO enabling the feature for smaller filesystems i nonsense, but it is something that is not under our control.

Here, you are completely right, only one way to test blocks allocation outside of UINT_MAX range is to use large volume, filled with real data, I am thinking about renting FreeBSD server somewhere, because I do not have access to large drives with TB sizes.

In D11530#238821, @thisisadrgreenthumb_gmail.com wrote:

In D11530#238803, @pfg wrote:

You can use the existing ext4gd fields but for the others we need to have extra care.

I think/suspect the 64BIT flag needs a 64 bit system and basically breaks the on-disk compatibility: I recall it was causing issues with some bootloaders.

The feature, just called 64bit, but, as I told, it is does not related to base types sizes, it is only about increasing size of struct ext2_gd, to add additional fields. Could you please describe about bootloadres? Do you mean, that FreeBSD ext2fs uses to mount boot volume somewhere?

You can use the existing ext4gd fields but for the others we need to have extra care.