From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 8 22:52:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 964B82CB for ; Sat, 8 Jun 2013 22:52:20 +0000 (UTC) (envelope-from erdgeist@erdgeist.org) Received: from elektropost.org (elektropost.org [217.13.206.130]) by mx1.freebsd.org (Postfix) with ESMTP id E9B66180F for ; Sat, 8 Jun 2013 22:52:19 +0000 (UTC) Received: (qmail 1290 invoked from network); 8 Jun 2013 22:52:11 -0000 Received: from elektropost.org (HELO elektropost.org) (erdgeist@erdgeist.org) by elektropost.org with CAMELLIA256-SHA encrypted SMTP; 8 Jun 2013 22:52:11 -0000 Message-ID: <51B3B59B.8050903@erdgeist.org> Date: Sun, 09 Jun 2013 00:52:11 +0200 From: Dirk Engling User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: FreeBSD Hackers Subject: Fix MNAMELEN or reimplement struct statfs X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2013 22:52:20 -0000 The arbitrary value #define MNAMELEN 88 /* size of on/from name bufs */ struct statfs { [...] char f_mntfromname[MNAMELEN];/* mounted filesystem */ char f_mntonname[MNAMELEN]; /* directory on which mounted */ }; currently bites us when trying to use poudriere with errors like 'mount: tmpfs: File name too long' /poudriere/data/build/91_RELEASE_amd64-REALLY-REALLY-LONG-JAILNAME/ref/wrkdirs The topic has been discussed several times since 2004 and has been postponed each time, the last time when it hit zfs users: http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html So I'd like to point to the calendar, it's 2013 already and there's still a static arbitrary (and way too low) limit in one of the core areas of the vfs code. So I'd like to bump the issue and propose either making f_mntfromname a dynamic allocation or just increase MNAMELEN, using 10.0 as water shed. Regards, erdgeist