Re: MAXNAMLEN vs NAME_MAX

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Sep 27, 2011 at 03:48:29PM +0700, Robert Elz wrote:
 >   | But it is better long term to move forward and allow for longer
 >   | names.
 > 
 > Why?

I was recently talking to some people who'd been working with some
(physicists, I think) doing data-intensive simulation of some kind,
and that reminded me: for various reasons, many people who are doing
serious data collection or simulation tend to encode vast amounts of
metadata in the names of their data files. Arguably this is a bad way
of doing things, but there are reasons for it and not so many clear
alternatives... anyway, 256 character filenames often aren't enough in
that context.

(This sort of usage also often involves things like 50,000 files in
one directory, so the columnizing behavior of ls is far from the top
of the list of relevant issues.)

If we do end up going through and doing a full set of compat functions
again, I think we should raise the limit to 1024... and maybe bump
PATH_MAX to say 4096 too.

 > The 255 limit was just because that's how many bytes a one byte length
 > field permitted, not because anyone thought names that long made sense.
 > But if you're going to increase it, why  stop at 511?  That number
 > means nothing - the next logical limit would be 65535 wouldn't it?

Well... yes but there are other considerations. As you noted, going
past one physical sector is problematic; going past one filesystem
block very problematic. Plus, as long as MMU pages remain 4K,
allocating contiguous kernel virtual space for path buffers (since if
NAME_MAX were raised to 64K, PATH_MAX would have to be at least that
large) could start to be a problem.

-- 
David A. Holland
dholland%netbsd.org@localhost