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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
