Fix MNAMELEN or reimplement struct statfs

[Jase Thew]

On 10/06/2013 16:52, John Baldwin wrote:
> On Saturday, June 08, 2013 9:36:27 pm mdf at freebsd.org wrote:
>> On Sat, Jun 8, 2013 at 3:52 PM, Dirk Engling <erdgeist at 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 at FreeBSD.org
FreeBSD Ports Committer


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1029 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20131114/d9dc7ea8/attachment.sig>