These links might help...
"Mostek, Jim" wrote:
> Hey Steve, I took a quick look at the Spanish page.
> The page compares XFS, ext2, reiser, and FAT32 with some basic tests.
> You can see the tables and understand them if you realize that the smaller
> numbers are better (number of seconds per op). He did writes, reads, deletes
> of a few things
> and XFS was faster for everything except the delete of a tar tree (which we
> because of the sync transaction on remove, right?).
> -----Original Message-----
> From: Steve Lord [mailto:lord@xxxxxxx]
> Sent: Thursday, May 10, 2001 7:00 AM
> To: redhat.angus
> Cc: linux-xfs
> Subject: Re: Benchmark
> > What to think of these results ?
> > http://bulma.lug.net/body.phtml?nIdNoticia=626
> Thanks for the pointer,
> That's in Spanish right? We used to have a Spanish speaking developer,
> it would be interesting to read the text, if I can remember how to use
> babelfish.... OK, interesting.
> > compared to the comment of Alan Cox concerning file deletion ?
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=98941976516596&w=2
> > >XFS is very fast most of the time (deleting a file is sooooo slow its
> > >like using old BSD systems). Im not familiar enough with its behaviour
> > >under Linux yet.
> > Do you have plan (SGI guys) to work on improve performances concerning
> > file deletion since it is obviously about the only case where XFS lose ?
> If there were about 20 days in a week and 48 hours in a day we might
> just have time to do everything. There has been a design for speeding
> this up for several years (yes years) but there has never been the
> bandwidth to implement it. It involves major structural changes in XFS
> and there are probably half a dozen people in the world with enough
> understanding of the code to attempt it (and only two of us work for SGI
> So yes I would like to, but it is still way way down the list (not ordered):
> o Fix NFS problems in linux xfs which some people have reported
> o support block sizes other then the page size
> o rework some vm code usage which will be hard to get into Linus's tree
> o complete realtime subvolume support
> o get a standard acl/extended attribute api
> o get code accepted by Linus
> o keep up with this email list!
> + the internal list of other things you do not get to see and which contains
> some MUCH larger work items than the above.
> So yes, I would like to do this, but....
> > -David