Date: Tue, 09 Aug 2016 11:09:17 +0200 From: Harry Schmalzbauer <freebsd@omnilan.de> To: Kurt Jaeger <lists@opsec.eu> Cc: Rick Macklem <rmacklem@uoguelph.ca>, FreeBSD Stable <freebsd-stable@freebsd.org>, Doug Ambrisko <ambrisko@ambrisko.com> Subject: Re: 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] Message-ID: <57A99DBD.40501@omnilan.de> In-Reply-To: <20160809053214.GW96200@home.opsec.eu> References: <57A79E24.8000100@omnilan.de> <YQBPR01MB0401201977AEA8A803F27B23DD1A0@YQBPR01MB0401.CANPRD01.PROD.OUTLOOK.COM> <57A83C78.1070403@omnilan.de> <20160809053214.GW96200@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
Bezüglich Kurt Jaeger's Nachricht vom 09.08.2016 07:32 (localtime): > 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 ? Good question, bad answer: No I had been told not to file a PR at that time because unionfs overhaul was planned/needed. Partial fixes would have been counterproductive in that state and not "the right way to go". Looks like overhaul hasn't really happened during the last 4 years and since I was happy with the partial patch, I haven't followed unionfs development. In the mean time I remember that lots of fs-stress-tests were added to the FreeBSD test suite, but I'm not familar with a single one, even not with ATF and the like, and won't find the time to dig into them. So presently I hesitate picking up that old issue and file a PR, because developers resources are extremely limited regarding unionfs, and the PR should be attended by someone who has time and knowledge to make developers life easier by providing qualified analysis and tests. All I could do at the moment is to point at a dysfunction, which is documented in the man page, which isn't really helpful/needed. >> 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 ? Sadly, the same answer with similar reasons is true. I asked Doug Ambrisko (the author of the mount_bigger_2_1.patch) at 10.2-BETA time (2015/07/10) about progress and future handling of his patch. He answered that Marshal Kirk McKusik asked him not to continue in that direction, since »it would make the 64 bit inode work harder«. So we agreed continuing being happy with the patch in our world, leaving the rest unhappy ;-) See the link to that discussion above. I was kind of astonsihed that this patch still applies to 11 and it seems 11 still has the MNAMELEN limitation besides make_dev_p() ability to handle extended lengths. CC'ed Doug, perhaps he joins this thread calrifying things. The unionfs thing is a edge-case thing, but MNAMELEN is much more important, imho, since ZFS is one of FreeBSD's most appreciated "new features" and this MNAMELEN limit needlessly counteracts ZFS' deployment. Of course I'll keep nagging from time to time ;-) And file PRs if not told otherwise :-) -Harry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?57A99DBD.40501>