Globbing (was Re: HAMMER update 10-Feb-2008)

[Bill Hacker]

> <20080211132514.GF48892 at staatsfeind.org> <47B05CD4.80102 at fs.ei.tum.de>
In-Reply-To: <47B05CD4.80102 at fs.ei.tum.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 36
Message-ID: <47b065cb$0$855$415eb37d at crater_reader.dragonflybsd.org>
NNTP-Posting-Host: 218.253.81.177
X-Trace: 1202742731 crater_reader.dragonflybsd.org 855 218.253.81.177
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:12083

Simon 'corecode' Schubert wrote:
> Matthias Schmidt wrote:
>> * Oliver Fromme wrote:
>>> A few years ago FreeBSD increased the limit to 256 KB.
>>> I don't know if DragonFly did the same, but it doesn't
>>> matter much
>> Nope, we haven't.  Our size is still 65536, FreeBSD has 262144.
>> But I don't see any reason not to increase the limit.
> 
> I don't see ANY reason why to increase it.  There is simply NO POINT in
> doing so.  It will ALWAYS be a limit.  Limit keeps being limit, thus no
> change in limit necessary, as it doesn't change the situation.  QED.
> 
> cheers
>   simon

JFWIW, the limit I was hitting was indeed already the higher number, as 
the server in question was running FreeBSD 6.2-RELEASE.

So - yes - there's always a limit of some kind, and even 1024 KB would 
not have helped here by enough to matter.

But times, and needs, even for slightly improved 'convenience' of 
hitting a limit less often, need to change with them, do they not?

I refer not to the weird / one-off case of 80+ GB being dumped into one 
subdir overnight, but rather to the far more common situation of longer 
filenames than we were once accustomed to.

Those will become more prevalent, not less so, going forward, and they 
eat into the available limit just as fast as greater file-count.

Regards,

Bill