I am starting to concur that this call may be obsoleted.
Let me add the kqueue maintainer and the fuse maintainer (Alan added kqueue support to fuse) as they may shed some more light on this

Committed as r350970.

Committed as r350969.

Fix typo

I was busy in the hospital (visiting not as patient) and didn't get the chance to approve it ... Huge thanks for doing this!

This passes "mandoc -Tlint".

This passes "mandoc -Tlint".

Fixes.

In D15687#459500, @antoine wrote:

Did you verify that the problem on i386 described in r251668 no longer occurs?

I think the problem in libssp_nonshared.a is brought in bogusly by the
libc.ldscript.

Its an ext4 feature, linux calls it crtime (creation time), just to be different ;).

In general I prefer we support a lower number of the protocol but that we support it well.

In D20598#450509, @gerald wrote:

Is there anything to be done for modern versions of GCC (GCC 8 or later)?

I think andreast@ and gerald@ may want to be kept in the loop for the GCC update then :).

Very exciting ... will upstream GCC require changes as well?

Adding fsu@ in case he wants to mention something else :).

Yes, we do fully support ext4 read and write in FreeBSD 12+. We also support Extended Attributes, ACLs, and most features with the exception of journalling and encryption. As mentioned in BSDNow, 12.1 will have a DTrace provider.

Thanks for working on this. For the record,

The changes seem correct.
I don't think a simple phabricator acceptance from a committer is suficient approval for a non src committer though, so I hereby explicitly approve it.

This has rusted since the last revision: fts had some changes (mostly just updated prototypes) and glob has been rewritten.
It needs some fresh eyes into it (cc'ing brooks in case he wants to take over).

Most of these don't make sense as they cant overflow, and those that do were committed.

This was committed as r337456.

Is this still a valid review? I recall something related was committed.

I still hope to hear from the DTrace experts, but I like this very much. Thanks!

Very cool (but I am biased since I suggested the fusefs-dtrace changes as a starting point)!

In D19325#415619, @mckusick wrote:

I recently added the new error EINTEGRITY which is intended for use when a cylinder group or other filesystem structure has an integrity error.

Upon further thought: the situation is very different for ext2fs than to a filesystem in which the all the system depends as in UFS.

In D19327#414960, @fsu wrote:

In D19327#413791, @pfg wrote:

Note why we specifically set ip->i_flags = 0 since r294652:

The ip->i_flags will be zero in all cases inside this function because we does not read new inode from disk at all for now and inode is allocated thru malloc with M_ZERO flag.

OK, you are rught, we were not allocating (with M_ZERO) this before.

Hi Kirk;
We have this as a panic in UFS, as well.

We should probably keep this panic for consistency with UFS, which also panics on this case.