Date: Thu, 14 Nov 2013 21:32:17 +0000 From: Jase Thew <jase@FreeBSD.org> To: John Baldwin <jhb@freebsd.org>, freebsd-hackers@freebsd.org Cc: mdf@freebsd.org, Dirk Engling <erdgeist@erdgeist.org> Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <52854161.6080104@FreeBSD.org> In-Reply-To: <201306101152.17966.jhb@freebsd.org> References: <51B3B59B.8050903@erdgeist.org> <CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ@mail.gmail.com> <201306101152.17966.jhb@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On 10/06/2013 16:52, John Baldwin wrote:
> 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?
>
Hi folks,
Has there been any progress on addressing this issue? With the advent of
pkgng / poudriere, this limitation is really becoming a frustrating problem.
--
Jase Thew
jase@FreeBSD.org
FreeBSD Ports Committer
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQJ8BAEBCgBmBQJShUFrXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGNzY3ODIxQkE1MTQ4MjNFQ0RGNUM3QkRE
NEU2NUM4QkZGMUMzODI5AAoJENTmXIv/HDgp/4QP/RyhATKVUf7H6jyrZhb+tCeV
Li1rJ4w8Z5fK7C9vjqfl06sLezm/fvZb7Sk5GViP/LcvqKYjjCdheq+bdFikpQkT
DbTNZEZAW8qDvEG/wpiShim+xahOhn6wJwC24ctrMw+ICvMbsUiol0rXu+NNEejA
uA38yJ+J6MrrJklSSj+bVXcTSWrsSXFZCDalV6aF+nTdH4ImV4vsO3liSQvEIU8s
OteJgpSVgruJrPY/7Pxe9t943KAbuWNG1guH0dD+mxH/9cgEDzttrvGXVBhYMDbH
9gy2KV4mr5RK8cCsDjwXgkXjPn51y63W6X6vVTo25WDIwQhDKMM4YE57LUOFG+s0
ykjh2fWgWJrtVyKpBVx+ikDOnPS6S6lKS3ucKQJHfRuN2SXyUVGudMbAcMUuTsz/
Hoy3IIQW2o1rDMtmrSx4beXCV9cd/BCNM0Q2ESIQcQQXD76Bp4qEXns+tNhSR3SS
KtF7hGWWjxAicUzm8mc1UyL6IQgW0TIVvbEbGRkiNqdL5mNj4laaWE720kFB7BDl
kK7reJ0500YKOjgAdZK7ZgcSlMRZU42eh09YkYZxdIzREFPAz86CNu76hFa7b6gX
sAf/VRC0aeF1sjCpvD9VnOECTs5KbTOOfWeLsLwnhqj0xfSnEHoka2ssYmVBBvyP
/qehrfqbOCKrGOfwzYU7
=78eZ
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?52854161.6080104>