Reiserfs vs XFS .. Now : How to improve IO disk speed.
linux-poweredge.lists at tisc.de
Wed Apr 12 03:05:34 CDT 2006
On Wed, Apr 12, 2006 at 09:38:08AM +0200, Johan De Meersman wrote:
> >To give more info : we got 14 disk of 300 GB 10K , RAID 5 config. That
> >is linked with 2 U320 to our file server.
> Changing out the disks for 15Ks would help, as would replacing them by
> smaller ones - but the latter obviously requires rebuilding the raid
> array because you're going to run out of space.
Why should smaller ones make a difference? I doubt that - larger drives
usually have higher data density and therefore higher throughput. It
shouldn't matter for access times.
> >We use the array as a DB server, I mean, a lots of little file that
> >contain what should be in a real DB .. Yes I know , we should use a real
> >DB system .. But when you got everything setup .. You don't want to
> >change things.
> ReiserFS, being an object-based filesystem, has a number of similarities
> to a DB :-)
To my understanding, ReiserFS uses hashing anyway, so you're almost
independent of directory size. It also stores small files in the FS
structure itself, so there may(!) be improvements. I don't know anything
about XFS though.
> >2- Do an other File server that will split the load .. (Also more ram
> >for cache)
> obviously, but I think it's a reasonable assumption that you'll need to
> change the application to be awares of this, so you can use the
> opportunity to implement the filename hashing I mentioned previously as
> well - no (affordable) hardware solution is going to provide you with
> the speed-up that that will give you.
I don't think that filename hashing will make a difference. At least
ReiserFS was designed to allow millions of files per directory. XFS
should scale as well.
> >>I agree that filesystem choice may not help much. Don't think there's much
> >>to index in a flat directory.
> You'd be surprised how different filesystems can behave when faced with
> large numbers of small files.
Indeed. One could also try exte3 with hashed directories. I'm not sure
whether this is standard, though - just heard about it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://lists.us.dell.com/pipermail/linux-poweredge/attachments/20060412/a468a78d/attachment-0001.bin
More information about the Linux-PowerEdge