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