xfs
[Top] [All Lists]

Re: xfs performance problem

To: Linux fs XFS <xfs@xxxxxxxxxxx>
Subject: Re: xfs performance problem
From: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sun, 1 May 2011 16:08:44 +0100
In-reply-to: <19901.28769.553575.864887@xxxxxxxxxxxxxxxxxx>
References: <4DB72084.8020205@xxxxxxxxxxx> <4DB74331.3030804@xxxxxxxxxxxxxxxxx> <4DB75C6D.1080901@xxxxxxxxxxx> <19898.53907.842827.480883@xxxxxxxxxxxxxxxxxx> <20110501084919.GE13542@dastard> <19901.28769.553575.864887@xxxxxxxxxxxxxxxxxx>
[ ... ]

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

<Prev in Thread] Current Thread [Next in Thread>