Re: xfs performance problem

Peter Grandi
2011-05-01T15:05:58Z

[ ... ]

>> [ ... Extracting a kernel 'tar' with GNU tar on 'ext3': ]
>>> real 0m21.769s
>> [ ... Extracting a kernel 'tar' with GNU tar on XFS: ]
>>> real 2m20.522s

>>> [ ... ] in most cases the wrong number is the one for 'ext3'
>>> on RAID1 (way too small). Even the number for XFS and RAID0
>>> 'delaylog' is a wrong number (somewhat small) in many cases.

[ ... ]

> % mount -t ext3 -o relatime /dev/sdb /mnt/sdb
> % time sh -c 'cd /mnt/sdb; star -x -b 2048 -f /tmp/linux-2.6.38.tar; cd /; umount /mnt/sdb'
> star: 420 blocks + 81920 bytes (total of 440483840 bytes = 430160.00k).

> real 12m49.610s
> user 0m0.990s
> sys 0m8.610s

[ ... ]

> In this discussion it is rather comical to make an argument
> based on the speed of IO using what is in effect EatMyData as
> described here:

> http://talk.maemo.org/showthread.php?t=67901

Just for confirmation here is the fantastic "performance" of
'ext3' with EatMyData:

% mount -t ext3 -o relatime /dev/sdb /mnt/sdb
% time sh -c 'cd /mnt/sdb; eatmydata star -x -b 2048 -f /tmp/linux-2.6.38.tar; cd /; umount /mnt/sdb'
/bin/star: 420 blocks + 81920 bytes (total of 440483840 bytes = 430160.00k).

real 0m28.917s
user 0m0.310s
sys 0m2.410s

Surprise surprise :-) the duration is much the same as GNU tar
or 'star' with '-no-fsync'.

Well, 'ext3' can do a rate a bit over 1,300 on a 100IOPS sort of
drive, but only in the EatMyData (plus 'umount') world not the
real world. That is where the 38,100 files are run in effect as
a single large commit.