Date: Sat, 8 Jun 2013 18:36:27 -0700 From: mdf@FreeBSD.org To: Dirk Engling <erdgeist@erdgeist.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ@mail.gmail.com> In-Reply-To: <51B3B59B.8050903@erdgeist.org> References: <51B3B59B.8050903@erdgeist.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Cheers,
matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ>