From owner-freebsd-fs@FreeBSD.ORG Thu Feb 19 10:28:18 2015 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2070385F for ; Thu, 19 Feb 2015 10:28:18 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id D71E7EC2 for ; Thu, 19 Feb 2015 10:28:17 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 0FFBF421582; Thu, 19 Feb 2015 21:27:58 +1100 (AEDT) Date: Thu, 19 Feb 2015 21:27:50 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Rick Macklem Subject: Re: current status RE: "File name too long" issues In-Reply-To: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> Message-ID: <20150219203111.W4301@besplex.bde.org> References: <1545385378.6062525.1424311788292.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=Za4kaKlA c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=6I5d2MoRAAAA:8 a=9ki36j1ue2UxshM84WIA:9 a=CjuIK1q_8ugA:10 Cc: freebsd-fs@freebsd.org, Konstantin Schukraft 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 10:28:18 -0000 On Wed, 18 Feb 2015, Rick Macklem wrote: > Konstantin Schukraft wrote: >> I just realised I only sent this email to freebsd-questions@, I >> ... >> - -------- Forwarded Message -------- >> ... >> 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. mount() used to work. The saved pathname in the statfs struct is only informational, but mount() has been broken to make this the limit on the syscall. This doesn't even work to give a uniform limit, since some file systems save the path in the superblock and have more or less space than MNAMELEN for this, depending on the file system. > However, FreeBSD cannot do this, since it breaks the statfs(2) syscall > interface and users of it. Unbreaking mount() doesn't break the ABI. Of course, everything using struct statfs can only display a truncated name, and there is no alternative to using struct statfs since the name is not saved anywhere else. Except sometimes in superblocks, but there is no user API to fetch the name from there. > 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. BSD-old through FreeBSD-4 does this without any patch. Bruce