Thus spake Chris Lamb, on Tue, Mar 05, 2002 at 08:28:35AM -0800:
wafl.maxdirsize 10240
or about 300000 files.
Unless your software engineers generally use absurd 40-character filenames, like ours tend to... :-)
No, our software engineer was DJB (Bernstein) :) And our filenames tend to be big yes, they're maildir:
root@mail:/maildirs/user/Maildir/new# ls -1 1011623164.19222.mail4,S=1415 | wc -c 30
No, we have quotas, file size and file number on each user mail account, so the maildirs can't grow that much. And the maildirs are hash using md5 and some parsing so there's really a "small" number of dirs/files in each dir.
I figured that you must have done something like that, because most folks realize pretty early on that putting 10's of thousands of files in shallow (or flat!) directory structures in an application like that just doesn't scale well at all. But the symptoms you described were fairly similar to what we were seeing, so I figured I'd toss it out there.
No, more than 30/40 thousand it simply doesn't work. It is too sluggish to be usable!
We had a similar problem at the beggining with 70000+ dirs on one dir but the simptoms where not the same. We only noticed a sluggish behavior when ls-ing the dir but no "ENOSPC" that I can remember. By the way, what does "ENOSPC" really mean?
ENOSPC is the error code in Unix for "No space left on device".
Ok, related with wafl.maxdirsize , I see.
Cheers,
-- Chris
-- Chris Lamb, Unix Guy MeasureCast, Inc. 503-241-1469 x247 skeezics@measurecast.com
-
Jose Celestino