Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion

Dan Oglesby
2006-07-31T17:46:32Z

On Mon, 2006-07-31 at 19:16 +0200, Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 11:47:00 -0500, Dan Oglesby <doglesby@teleformix.com> wrote:
> > On Mon, 2006-07-31 at 18:22 +0200, Jan-Benedict Glaw wrote:
> > > On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich <reiser4@blinkenlights.ch> wrote:
> > > > A colleague of mine happened to create a ~300gb filesystem and started
> > > > to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
> > > > to the new LUN. At about 70% the filesystem ran out of inodes; Not a
> > > So preparation work wasn't done.
> >
> > As someone who is currently planning to migrate ~100GB of stored mail to
> > the Maildirs format, it was pretty clear early on that EXT3 would not
> > cut it (from past and current experiences), and not just for the sake of
> > calculating inodes.
>
> Uh? Where did you face a problem there?
>

Past experiences dealing with systems that generate several thousand to
tens of thousands of files a day, adding up to well in the millions over
the course of normal production (this is not for a mail server, BTW).
Once we got close to a million files, filesystem transactions started
bogging the system, driving the load over 50. Simply switching to
ReiserFS v3 allowed us to go well past the number of files EXT3 could
handle reasonably and the max load stayed right around the number of
CPUs the system contained (typically 8).

There is a LOT going on with these systems, not just filesystem
transactions. EXT3 does not do well in our environment at all.

> With maildir, you shouldn't face any problems IMO. Even users with
> zillions of mails should work properly with the dir_index stuff:
>
> tune2fs -O dir_index /dev/hdXX
>
> or alternatively (to start that for already existing directories):
>
> e2fsck -fD /dev/hdXX
>
>

I've been tuning EXT3 to see what performance I can get for the mail
server, and it's just not there compared to ReiserFS with minimal
tuning.

> Of course, you'll always face a problem with lots of files in one
> directory at getdents() time (eg. opendir()/readdir()/closedir()), but
> this is a common limit for all filesystems.
>
> MfG, JBG
>

Of course, but the issue is EXT3 does this a whole lot worse than
ReiserFS v3 from my experiences.

At any rate, that's about all I have to say about this issue. I'll be
patiently waiting to see ReiserFS v4 included in the main kernel, so I
have less hoops to jump through to implement the latest and greatest
from Namesys.

--Dan