lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1154367862.7964.47.camel@localhost>
Date:	Mon, 31 Jul 2006 12:44:22 -0500
From:	Dan Oglesby <doglesby@...eformix.com>
To:	Jan-Benedict Glaw <jbglaw@...-owl.de>
Cc:	Adrian Ulrich <reiser4@...nkenlights.ch>,
	Matthias Andree <matthias.andree@....de>,
	vonbrand@....utfsm.cl, ipso@...ppymail.ca, reiser@...esys.com,
	lkml@...productions.com, jeff@...zik.org, tytso@....edu,
	linux-kernel@...r.kernel.org, reiserfs-list@...esys.com
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org
	regarding reiser4 inclusion

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@...eformix.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@...nkenlights.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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ