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@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
