[rhn-users] Re: ReiserFS and tuning ext3

Bill bill at magicdigits.com
Mon Jun 19 14:46:16 UTC 2006


Try a RAID 1 or 0+1 for immediate help, along with a caching controller. This allows 
far more disk drive heads to cover your data increasing the probability that some head 
will be nearer your data than now. From my studies, I've seen a 90% increase in speed.

For millions of little files, defragmentation is a good thing and works for you. If 
you have, say, 2 huge files (index and data) then not so good. Shuffling 2 files like 
a deck of cards is better for that.

Another thing to try is copy your active disk to a backup disk first, then to tape. 
Tapes have a characteristic that if you do not provide data in time, they must stop, 
rewind a little, and start again - killing your throughput. Disk to disk first should 
remove that by effectively defragmenting the backup disk.

Bill Watson
bill at magicdigits.com

---------- Original Message -----------
From: "Carl Provencher" <Carl.Provencher at sit.ulaval.ca>
To: "Red Hat Network Users List" <rhn-users at redhat.com>
Sent: Mon, 19 Jun 2006 10:26:17 -0400
Subject: RE: [rhn-users] Re: ReiserFS and tuning ext3

> Hi every one,
> 
> We actually have a big problem with the time of our system backup takes 
> (Networker from Legato).  We made a lot of tests and we conclude that problem 
> causes by the random distribution of our data on partition.
> 
> Our application is a mail server with cyrus-imapd (and murder fonctionnality)
>  .  We have 4 back ends with 200 Gb and 6 393 124 files.
> 
> I made a little perl program to create a random distribution and we made this test:
> 
> 	* Take a full backup.
> 	* Empty partition
> 	* Did a full restore
> 	* At this moment the data was stored in a same order of directory
> 	* We took a full backup:  the thru put was ok (approx 8 Mb/sec)
> 	* We run my perl program to create a random distrution
> 	* We took another full backup: the thru put was drop to 4Mb/sec.
> 
> We are sure that the problem was cause because ext3 filesystems didn't 
> optimized the location where it writes a new file.  When we made a full backup,
>  the backup process read file in the order of ext3 index (backup files in 1st 
> directory, files of 2nd directory and so on), i.-e.: read sequentially data 
> distributed randomly on disk.  The head of drive move randomly from border to 
> center of drive.  If data was physically grouping (it's not case) by directory,
>  that minimize the head drive movement and optimized a cache drive usage.
> 
> We actually made test with ReiserFS to verify if, like his reputation said, it 
> more preferment with a million of little files.
> 
> We have this problem with all of our back ends and with an e-learning web 
> server (WebCT) with 8 millions of files.
> 
> This problem cause our full backup takes approximatively 20 hours.  This 
> problem obliges us to add back ends (for mail system) rather than to increase 
> our disk space on back ends. This is more expensive.
> 
> Some body experience same problem with ext3 or with another file system and 
> what you do to solve it?  If you have a web link, go4it.
> 
> Thanks
> ____________________________________________________________________
> Carl Provencher
> S.I.T., Université Laval
> Tél.: (418) 656-2131 poste 8719
> http://www.sit.ulaval.ca/
> ____________________________________________________________________
> Avis relatif à la confidentialité / Notice of Confidentiality /
> Advertencia de confidencialidad
> <http://www.rec.ulaval.ca/lce/securite/confidentialite.htm>
> 
> | -----Message d'origine-----
> | De : rhn-users-bounces at redhat.com [mailto:rhn-users-bounces at redhat.com] De
> | la part de Eddy Harvey
> | Envoyé : 19 juin 2006 09:46
> | À : rhn-users at redhat.com
> | Objet : RE: [rhn-users] Re: ReiserFS and tuning ext3
> | 
> | Is there any reason anybody would ever use reiserfs instead of ext3?
> | 
> | I thought the whole point of reiser was to provide journalling back in the
> | days when ext2 didn't support journalling.  And then when they created
> | ext3,
> | it made reiser obsolete.
> | 
> | 
> | 
> | > -----Original Message-----
> | > From: rhn-users-bounces at redhat.com
> | > [mailto:rhn-users-bounces at redhat.com] On Behalf Of Tom Weeks
> | > Sent: Sunday, June 18, 2006 8:36 PM
> | > To: rhn-users at redhat.com
> | > Subject: Re: [rhn-users] Re: ReiserFS and tuning ext3
> | >
> | > [old reply to an old post.. sorry]
> | > On Saturday 22 April 2006 11:41, Ken Dyke wrote:
> | > > On Fri, Apr 21, 2006 at 01:01:29PM -0400, Kvetch
> | > (kvetch at gmail.com) wrote:
> | > > > Does anyone know why RH stopped supporting ReiserFS after Ent2.1?
> | > >
> | > > I certainly can not speak for RH and may be way of base but
> | > I think it
> | > > has to do with extended attributes for support of selinux.
> | >
> | > Well *I* heard that Red Hat was wanting to keep all vfs code
> | > in common and in the base kernel.. and Mr Reiser refused and
> | > would not let his vfs code go from his filesystem module.
> | > But then we also have no other journaling filesystems either
> | > (JFS, XFS, etc), so that lends itself to the theory that RH
> | > is just wanting to upsell their customers to use GFS for everything.
> | > Anyway, now even if you try to add the reiser module to the
> | > Red Hat kernel, you'll see that Red Hat went to far as to
> | > remove all the "hooks" for even including the module in their
> | > kernel!  Wow..  That's not cool...  You either have to
> | > totally hack up the RH kernel manually (which often  breaks
> | > the "patching house of cards"), or just go ahead and violate
> | > the RH support contract and switch to a standard kernel.org
> | > kernel.  That really sucks.
> | >
> | > I'm a big Red Hat guy myself... but I'll be the first to say
> | > that this stance of theirs is one of their biggest mistakes
> | > (right up there with their previous stance of leaving out the
> | > latest MySQL for licensing reasons).  Just plain stupid and
> | > they need to give in.
> | >
> | > Their stance kind of takes Red Hat out of the "Enterprise OS
> | > Circle" if you ask me.  If one has fast journaling FS needs,
> | > they would be better off either running Fedora Core, the
> | > modified CentOS kernel, or if you need the enterprise SLAs,
> | > maybe even SLES (Novel).
> | >
> | > Tweeks
> | >
> | > _______________________________________________
> | > rhn-users mailing list
> | > rhn-users at redhat.com
> | > https://www.redhat.com/mailman/listinfo/rhn-users
> | >
> | 
> | _______________________________________________
> | rhn-users mailing list
> | rhn-users at redhat.com
> | https://www.redhat.com/mailman/listinfo/rhn-users
> 
> _______________________________________________
> rhn-users mailing list
> rhn-users at redhat.com
> https://www.redhat.com/mailman/listinfo/rhn-users
------- End of Original Message -------




More information about the rhn-users mailing list