Re: LWN.net article: creating 1 billion files -> XFS looses

[Dave Chinner <david@fromorbit.com>]

On Thu, Aug 19, 2010 at 02:45:22PM +0200, Michael Monnerie wrote:
> On Donnerstag, 19. August 2010 Christoph Hellwig wrote:
> > The creation and deletion performance is a known issue, and too a
> >  large extent fixes by the new delaylog code.  We're not quite as
> >  fast as ext4 yet, but it's getting close.
> > 
> > The repair result looks a lot like the pre-3.1.0 xfsprogs repair.
>  
> Yes I know. I thought some XFS dev might contact the Author to do some 
> re-testing, as a reputation is quickly destroyed by such articles and 
> takes long to be returned. Just this week I had a friend in a FS 
> discussion saying "ins't XFS destroying/zeroing files on power 
> failure?". That information is ancient, but things like that stay in 
> peoples brain for(almost)ever.

Don't worry too much - I have the details of the test that was run
and alredy know why XFS appeared so slow: it was single threaded.
Immediately, that means XFS will be slower to create 1b files
regardless of any other detail.

Look at it this way - the initial numbers I'm seeing on my test rig
are sustained create rates of about 8,000/s with default mkfs/mount
options (i.e. no tuning, no delayed logging, 32k logbsize, etc) and
it is burning exactly one of 8 CPUs in the VM. I know I can get an
order of magnitude better performance out of XFS on this VM....

It'll take me a few days to run the numbers to be able to write a
solid reply, but I have every confidence that a "create 1b inodes"
benchmark tuned to XFS's strengths rather than one designed to avoid
ext4's weaknesses will show very, very different results.

In the meantime, there is no need to start a flamewar. ;)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs