freebsd stable - Aug 2016 - unionfs bugs, a partial patch and some comments [Was: Re: 1-BETA3 Panic: __lockmgr_args: downgrade a recursed lockmgr nfs @ /usr/local/share/deploy-tools/RELENG_11/src/sys/fs/unionfs/union_vnops.c:1905]

Bez?glich Rick Macklem's Nachricht vom 07.08.2016 23:34
(localtime):
> Harry Schmalzbauer wrote:
>> Hello,
>>
>> I had another crash which I'm quite sure was triggered by
mount_unionfs:
> Just in case you are not already aware, unionfs is always broken. Read
> the BUGS
> section at the end of "man mount_unionfs". If it were easy to
fix,
> someone would
> have done so long ago. Yes, some use it successfully, but if not...
> 
> Sorry, but I suspect that is how it will remain, rick
Thanks for the hint, not happy to hear that, but I was not aware of that
explicit warning in man 8 mount_unionfs :-(

This feature is utterly important for me (all my productive machines
have "/" read-only mounted and "/etc" is an union to a
writable, synch
mounted separate fs), so back in 2012, after a lot of locking redesign
has been done in 9-current, I got Attilio Raos attention and he gave out
some test patches for 9.0.
He was aware of missing locking adjustments, but patches addressing the
majority of them didn't work.
Since then I'm draging a minimal patch which prevents at least the
kernel panics for me.
Unfortunately I don't have the skills to continue Attilio Raos work.

Just for anybody else needing unionfs:
https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch

This patch still applies and I'm successfully using this (unmodified) up
to FreeBSD-10.3 and never had any panic in all these years.

I will continue using it for FreeBSD-11 and I guess it will also prevent
my last reported panics.
But I wanted to take part in the BETA test without local modifications
at first.

Another very importend usage scenario of unionfs for me is for my build
host(s). I'm (nfs4-)sharing a svn-checked out read-only portstree. My
inofficial "ports/inofficial" directory perfectly shows up by
unionfs-mounting it below the unaltered portstree :-)

For me, unionfs is as important as ZFS (and nullfs) is in FreeBSD.

First thing to do for me, after I won in lottery, was to find someone
who can be sponsored fixing unionfs ;-) And bringing MNAMELEN into 21st
century state, matching ZFS needs:
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-November/048640.html
This is another patch I'm carrying for a very long time which solves
tremendous limitations for me. Without that, I couldn't use ZFS
snapshots in real world, along with a human-friendly dataset naming :-)

-Harry

Hi!
> Since then I'm draging a minimal patch which prevents at least the
> kernel panics for me.
> Unfortunately I don't have the skills to continue Attilio Raos work.
> 
> Just for anybody else needing unionfs:
> https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch
Is this referenced in any PR ? If not, can you create one ?
> First thing to do for me, after I won in lottery, was to find someone
> who can be sponsored fixing unionfs ;-) And bringing MNAMELEN into 21st
> century state, matching ZFS needs:
>
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-November/048640.html
> This is another patch I'm carrying for a very long time which solves
> tremendous limitations for me. Without that, I couldn't use ZFS
> snapshots in real world, along with a human-friendly dataset naming :-)
And is there a PR for that ?

-- 
pi at opsec.eu            +49 171 3101372                         4 years to go
!

On Mon, Aug 08, 2016 at 10:02:00AM +0200, Harry Schmalzbauer
wrote:
> Bez?glich Rick Macklem's Nachricht vom 07.08.2016 23:34 (localtime):
> > Harry Schmalzbauer wrote:
> >> Hello,
> >>
> >> I had another crash which I'm quite sure was triggered by
mount_unionfs:
> > Just in case you are not already aware, unionfs is always broken. Read
> > the BUGS
> > section at the end of "man mount_unionfs". If it were easy
to fix,
> > someone would
> > have done so long ago. Yes, some use it successfully, but if not...
> > 
> > Sorry, but I suspect that is how it will remain, rick
> 
> Thanks for the hint, not happy to hear that, but I was not aware of that
> explicit warning in man 8 mount_unionfs :-(
> 
> This feature is utterly important for me (all my productive machines
> have "/" read-only mounted and "/etc" is an union to a
writable, synch
> mounted separate fs), so back in 2012, after a lot of locking redesign
> has been done in 9-current, I got Attilio Raos attention and he gave out
> some test patches for 9.0.
> He was aware of missing locking adjustments, but patches addressing the
> majority of them didn't work.
> Since then I'm draging a minimal patch which prevents at least the
> kernel panics for me.
> Unfortunately I don't have the skills to continue Attilio Raos work.
> 
> Just for anybody else needing unionfs:
> https://people.freebsd.org/~attilio/unionfs_missing_insmntque_lock.patch
> 
> This patch still applies and I'm successfully using this (unmodified)
up
> to FreeBSD-10.3 and never had any panic in all these years.
Having spent some time looking at unionfs, I'm a bit skeptical that this
patch will address the panic you reported earlier, though I'd be
interested to know if it does. Reading the code, I think it will just
address an INVARIANTS-only assertion in insmntque1().

Unfortunately, unionfs is quite difficult to fix within the current
constraints of FreeBSD's VFS. unionfs_readdir() is a particularly good
demonstration of this fact: some callers of VOP_READDIR expect the
cookies returned by the FS to be monotonically increasing, but unionfs
has no straightforward way to make this guarantee.
> 
> I will continue using it for FreeBSD-11 and I guess it will also prevent
> my last reported panics.
> But I wanted to take part in the BETA test without local modifications
> at first.
> 
> Another very importend usage scenario of unionfs for me is for my build
> host(s). I'm (nfs4-)sharing a svn-checked out read-only portstree. My
> inofficial "ports/inofficial" directory perfectly shows up by
> unionfs-mounting it below the unaltered portstree :-)
> 
> For me, unionfs is as important as ZFS (and nullfs) is in FreeBSD.
> 
> First thing to do for me, after I won in lottery, was to find someone
> who can be sponsored fixing unionfs ;-) And bringing MNAMELEN into 21st
> century state, matching ZFS needs:
>
https://lists.freebsd.org/pipermail/freebsd-hackers/2015-November/048640.html
> This is another patch I'm carrying for a very long time which solves
> tremendous limitations for me. Without that, I couldn't use ZFS
> snapshots in real world, along with a human-friendly dataset naming :-)
> 
> -Harry
> 
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"