xfs performance problem

[Peter Grandi]

[ ... ]

>> [ ... 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.