Re: MAXNAMLEN vs NAME_MAX

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 26 Sep 2011 09:46:09 -0400
    From:        christos%zoulas.com@localhost (Christos Zoulas)
    Message-ID:  <20110926134609.8322A9711D%rebar.astron.com@localhost>

  | But it is better long term to move forward and allow for longer
  | names.

Why?

Certainly the original 14 byte limit was occasionally a nuisance (but
even that was better than 8+3 which was typical), but longer than 255?

Even using a utf-8 encoded filename, at 5 bytes/character, that's still
a 51 character filename, which is longer than rational - names >= 40
characters mean that on a standard 80 column display, ls can't even show
2 columns of names.

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?

511 is already too big to keep directory entries within one disc block
when using small blocks, so you've already lost the idempotent directory
entry write feature that was part of the original design (both v7fs and
ffs) (not just file system block writes, but actual drive writing, you
can't fix this just by making a larger minimum frag size, only by changing
drive electronics and/or microcode).

kre