From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 02:10:52 2015 Return-Path: Delivered-To: freebsd-fs@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 7A651199 for ; Thu, 19 Feb 2015 02:10:52 +0000 (UTC) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 27FA582A for ; Thu, 19 Feb 2015 02:10:51 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AXBQBxReVU/95baINbg1haBIMEv1YOhSNKAoFiAQEBAQEBfIQMAQEBAwEBAQEgKyALGxEDAQIBAgINGQIpAQkVCQgGCAIFBAEcBIgGCA26DJhHAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiW6CYYErCwUCARs0BwaCYoFCBYpDiFuDRoM4OIJYjm4iggEdgW4gMQEBBXxBfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,605,1418101200"; d="scan'208";a="191708739" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 18 Feb 2015 21:09:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 4BCABB3F28; Wed, 18 Feb 2015 21:09:48 -0500 (EST) Date: Wed, 18 Feb 2015 21:09:48 -0500 (EST) From: Rick Macklem To: Konstantin Schukraft Message-ID: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> In-Reply-To: <54E40E86.1030805@schukraft.org> Subject: Re: current status RE: "File name too long" issues MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.10] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 02:10:52 -0000 Konstantin Schukraft wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hi, > > I just realised I only sent this email to freebsd-questions@, I > intended to send a copy to freebsd-fs@ as well, given the nature of > the problem. So here you go, any input into this problem is > appreciated. > > > All the best, > > Konstantin > > > - -------- Forwarded Message -------- > From: - Mon Feb 16 14:26:58 2015 > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00800000 > X-Mozilla-Keys: > Message-ID: <54E1F020.8040107@schukraft.org> > Date: Mon, 16 Feb 2015 14:26:56 +0100 > From: Konstantin Schukraft > User-Agent: "" > MIME-Version: 1.0 > To: freebsd-questions@freebsd.org > Subject: current status RE: "File name too long" issues > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit > > Hi, > > this seems a rather old issue that's still alive, manifesting in NFS > mounts, nullfs mounts with jails, etc: > "Overly" long path names in these situations result in an error like > "mount_nullfs: : File name too long". I, for example, run into > this every time I try to setup a poudriere jail, others seem too. > > Since the forums didn't really provide an answer, I'll ask here: > Is there work currently being done on this issue? Because this reply: > https://docs.freebsd.org/cgi/getmsg.cgi?fetch=210593+0+/usr/local/www/db/text/2014/freebsd-questions/20141221.freebsd-questions > seems to indicate this has been fixed, which definitely isn't the > case > for many people, including myself. > > So what's the status on that? Am I overlooking something important? > As far as I know, the 88 byte limit for paths still applies. You can easily change the value of MNAMELEN in sys/sys/mount.h and rebuild everything from these modified sources. However, FreeBSD cannot do this, since it breaks the statfs(2) syscall interface and users of it. In svn's projects/ino64, there is work in progress on this + changing ino_t to be 64bits. Hopefully this work will make in it FreeBSD11. If there is a new system call that replaces the current statfs(2) that ends up with a different name, it might be possible to MFC this and have statfs(2) return a truncated path. I believe there is a patch floating around that allows NFS mounts with longer paths to work, truncating the path for statfs(2), but this is not in -current etc. If others know more or if I've gotten this incorrect, please correct me, rick > > Thank you, > > Konstantin > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCAAGBQJU5A5+AAoJEH3raMNeVmMFTkIP/2JaBgHwY84bTSc4OYGRAuCB > LxkGC3BdpGAxvE6BHJgrAPEPHDEhUUyuNwm/LiuvjqCqO+2e8yMEJ6vR69XBdKX1 > t2aXIlF/si/WUgDOHp9veuSb9a8aMz+C0aTXIb+OFwPDKfQu22NARp2edRVM1znT > 17unGUuM1qxxeW1jyEQbGqAxysDCNjCGPp6cVeJRL8b8eGjd8lNwe/6St9O6gDON > Yjj6RZGU5BXBruZk2Fn71U9mt+sbfAXUvs0tQpV805oW/ymQcxXVfkjBkqeh5ZlV > RthXswsqRmf4tUJX7A0lHRGL+8OFUxpTJGb+yrrDicH85NgpZGEh5BJGYeFE1jOk > uDnNmYx4EC2Qe9bHDqzCT3JtfjscsR2yzhP3TXaHicPOZsr9SjXQOE+OKp3luGUa > v9EsAXepRPFqgwn3qqEqBVgTXjeVWNOtFEFV0aEBmsEfco3q/ZpIV/hS3UpyK+Ed > 0L8SqrkRSyDJ6s6MTYpoHp/Q8AUT9wkoShJxKoAb/psSvHsmGRvbu0pweA9AMBw8 > 7bXkLY10WlCkkH8Vn9u4oUlvlKjGfBUMlTzW4laLE+1lAbW6gedNd7eerhI+Z3rS > NnVWuDBFWJyB08V+gDcJ4i/PfqCGJIJWqE6EQEr2pYSf5H542GZ7WgAJoENpi/C0 > m00aK6ZHvY28sAtR1zeh > =/tUC > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >