Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Jun 2013 11:52:17 -0400
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        mdf@freebsd.org, Dirk Engling <erdgeist@erdgeist.org>
Subject:   Re: Fix MNAMELEN or reimplement struct statfs
Message-ID:  <201306101152.17966.jhb@freebsd.org>
In-Reply-To: <CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ@mail.gmail.com>
References:  <51B3B59B.8050903@erdgeist.org> <CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday, June 08, 2013 9:36:27 pm mdf@freebsd.org wrote:
> On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling <erdgeist@erdgeist.org> wrote:
> 
> > 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.
> >
> 
> Gleb Kurtsou did this along with the ino64 GSoC project.  Unfortunately,
>  both he and I hit ENOTIME due to the job that pays the bills and it's
> never made it back to the main repository.
> 
> IIRC, though, the only reason for doing it with 64-bit ino_t is that he'd
> already finished changing the stat/dirent ABI so what was one more.  I
> think he went with 1024 bytes, which also necessitated not allocating
> statfs on the stack for the kernel.

He also fixed a few other things since changing this ABI is so invasive
IIRC.  This really is the right fix for this.  Is it in an svn branch 
that can be updated and a new patch generated?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201306101152.17966.jhb>