I ran stress test for 24 hours with D33312.99617.diff without seeing any problems.

In D33312#753182, @dougm wrote:

Which revision did you create the diff from?

I hope this is the kind of answer you're looking for:
commit e3044071dec1d752a7103b5ae55fe3cff2f5b957 (HEAD -> main, freebsd/main, freebsd/HEAD)

Which revision did you create the diff from?

All of the unions tests in stress2 runs without any issues when D33008.98931.diff is added.

I no longer see the message "mkdir.c:120: No such file or directory" with D32533.96980.diff applied.

I got this panic while testing with D32148.95756.diff:

I got this with a NON-DIAGNOSTIC build:

Looks good to me.

Peter, thank you for testing this out!

Do you think there's any value in committing gnop11.sh as-is? I know you said the I/O completed too quickly on your faster machine; would you prefer a shorter sleep, say 0.1s? Or would you rather have a different test altogether?

You should commit gnop11.sh as is. The stacked use of nullfs is definetly in the spirit of stress2.

In D31016#704507, @kib wrote:

In D31016#704447, @pho wrote:

All done. No problems seen.

20210722 19:00:47 all.sh done, elapsed 2 day(s), 04:40.10

And no nullfs issues observed? I am confused.

In D31016#703154, @pho wrote:

In D31016#703115, @mckusick wrote:

I am fine with the structure of this patch. I do ask that you await passing Peter Holm's tests before committing.

I have started a full test with D31016.92436.diff.

In D31016#703115, @mckusick wrote:

I am fine with the structure of this patch. I do ask that you await passing Peter Holm's tests before committing.

I still see this: https://people.freebsd.org/~pho/stress/log/log0139.txt

In D31016#702230, @jah wrote:

In D31016#701737, @mckusick wrote:

@jah - are you ready to have Peter Holm test these changes? If so, I will enlist his help.

Yes, in fact I've been using the unionfs/nullfs stress2 tests as the basis for crude manual testing of this code, but it would be nice to have something automated.
It'd be nice to have an automated that exercises recursive unmounts concurrently with both other recursive and non-recursive unmounts within the same stacked filesystem hierarchy.

I've added Peter here. I gladly help write any needed tests, but I could use some guidance on what we might already have that could be a starting point.

I ran all of the tcp tests I have followed by the problem test in a loop for 24 hours.
No problems seen.

In D29830#669416, @pho wrote:

This fixes the issue for me. I have started a full test on mercat1.

I ran tests with D29835.87758.diff for 8 hours without seeing any issues.

This fixes the issue for me. I have started a full test on mercat1.

With main-n246162-b87cf2bc841 I now get:

db> x/s version
version: FreeBSD 14.0-CURRENT #1 main-n246155-b6a572d03f6-dirty: Sun Apr 18 22:20:42 CEST 2021\012 pho@mercat1.netperf.freebsd.org:/usr/src/sys/amd64/compile/PHO\012
db>

Is this with or without the patch in this review?

D29752.87397.diff looks good to me. Tested with syscall fuzzing of:

This patch does not fix the issue for me using this test scenario:

I ran your test scenario plus the five other extattr scenarios I already had. LGTM.

I ran the 13 msdosfs tests I have two times followed by one write-intensive test in a loop for one hour.
No problems seen.

I ran the few zfs tests I have on openzfs_gc1c31a835-n244815-1f4c076e9e38 without observing any problems.

I ran 675 out of 723 stress tests with D24217.83480.diff without observing any problems,

I ran the 29 NFS tests I have with D28306.82766.diff. This was a 2 1/2 hour test.
No problems seen.

I ran tests with D28219.82645.diff for 6 hours. No problems seen.

I ran tests with D28219.82616.diff on amd64 for two hours. No problems seen.

I tested D28147.82306.diff on i386 for 8 hours and on amd64 for 47 hours. No problems seen.

I ran a two-hour test on two different hosts with D27956.81970.diff added.
No problems seen.

I ran stress tests on two different hosts for an hour. No problems seen.

I ran a full stress2 test on mercat1.