From owner-freebsd-stable@freebsd.org Tue Aug 9 09:09:26 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FC63BB28FC for ; Tue, 9 Aug 2016 09:09:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FEEA1A1A for ; Tue, 9 Aug 2016 09:09:25 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (mh0.gentlemail.de [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id u7999IOG084022; Tue, 9 Aug 2016 11:09:19 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (titan.inop.mo1.omnilan.net [IPv6:2001:a60:f0bb:1::3:1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 316B8E72; Tue, 9 Aug 2016 11:09:18 +0200 (CEST) Message-ID: <57A99DBD.40501@omnilan.de> Date: Tue, 09 Aug 2016 11:09:17 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Kurt Jaeger CC: Rick Macklem , FreeBSD Stable , Doug Ambrisko 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] References: <57A79E24.8000100@omnilan.de> <57A83C78.1070403@omnilan.de> <20160809053214.GW96200@home.opsec.eu> In-Reply-To: <20160809053214.GW96200@home.opsec.eu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Tue, 09 Aug 2016 11:09:19 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 09:09:26 -0000 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