From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 30 15:58:09 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 520DD747 for ; Thu, 30 Oct 2014 15:58:09 +0000 (UTC) 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 EC32DC90 for ; Thu, 30 Oct 2014 15:58:08 +0000 (UTC) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [78.138.80.135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id s9UFw5mF079021 for ; Thu, 30 Oct 2014 16:58:05 +0100 (CET) (envelope-from h.schmalzbauer@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 DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 123543D95; Thu, 30 Oct 2014 16:58:04 +0100 (CET) Message-ID: <5452600C.5030003@omnilan.de> Date: Thu, 30 Oct 2014 16:58:04 +0100 From: Harald 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: freebsd-hackers@freebsd.org Subject: Re: Fix MNAMELEN or reimplement struct statfs References: <20140415233133.GA14686@ambrisko.com> In-Reply-To: <20140415233133.GA14686@ambrisko.com> X-Enigmail-Version: 1.1.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF48E2C289B4AEEC87964F705" X-Greylist: ACL 119 matched, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [78.138.80.130]); Thu, 30 Oct 2014 16:58:05 +0100 (CET) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: 78.138.80.135; Sender-helo: mh0.gentlemail.de; ) X-Mailman-Approved-At: Thu, 30 Oct 2014 18:45:58 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 15:58:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF48E2C289B4AEEC87964F705 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, first sorry for the missing thread references in the header, I'm not subscribed to hackers@. bdrewery@ pointed me to this discussion in response to my question to stable@ (http://lists.freebsd.org/pipermail/freebsd-fs/2014-August/019949.html) Last promising post I found: > |/ > I have a new patch at: > /|/ > http://people.freebsd.org/~ambrisko/mount_bigger_2.patch > /|/ > that I tested against head. This should be pretty close to commi= ting > /|/ > unless people find some issues with it. > /|/=20 > /|/ In sys/kern/vfs_mount.c: > /|/ + mp->mnt_path =3D malloc(strlen(fspath), M_MOUNT, M_WAITOK); > /|/ + strlcpy((char *)mp->mnt_path, fspath, strlen(fspath)); > /|/=20 > /|/ This always strips the last byte off the fspath. > /|/=20 > /|/ I like that this only touches the kernel, so it does not break anyt= hing > /|/ regarding mount/umount of filesystems with short paths, including > /|/ (NFS) filesystems that do not respond. > /|/=20 > /|/ The patch does not enlarge f_mntfromname which may be a problem for= > /|/ nullfs. It is certainly a step forwards for poudriere but [ENAMETOO= LONG] > /|/ errors could still occur in more extreme situations. > / > Good point on nullfs. I'll look at fixing that. To do that I'm > changing mnt_path to mnt_topath so then I can have a mnt_frompath. > I'll add nullfs to my test cases. I'll need to run through the uses > of f_mntfromname. It was pretty easy with f_mntonname since it was > only allocated in one place just used a bunch of other place. I assume= > that mount root would be short. Thanks a lot so far for working hard on that problem! Is there anything newer than "mount_bigger_2.patch", which considers potential nullfs problems? I'm heavily using nullfs (without poudriere), but I'd give it a try on my rather lightly loaded local 10.1 storage box =E2=80=93 almost all snap= shots are useless, can't access them in case of the case; which happens frequently :-( Would I have to expect any nullfs regressions with the april (mount_bigger_2) patch?? Thanks, -Harry --------------enigF48E2C289B4AEEC87964F705 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAlRSYAwACgkQLDqVQ9VXb8ir2wCferAaRr0Zc86cFqifNQDc3+6U 9ysAoMeuk84ezCMsllfM6SHRu7ojUJsG =JLEc -----END PGP SIGNATURE----- --------------enigF48E2C289B4AEEC87964F705--