xfs performance problem
sorry, forgot to cc.
Am Mittwoch, 27. April 2011 schrieb Dave Chinner:
Quoted 16 lines · Benjamin Schindler
Quoted 14 lines
Hi
Since upgrading to newer kernels I have serious problems with xfs performance on my root fs.
It runs on a software raid 0 with 2 disks. On the same two disks, there are two more partitions running a software raid-1 with ext3. On the ext3 system, I have no issue, so I assume the drives are fine.
But on the xfs filesystem, extracting a linux kernel archive takes 5 minutes or more, running ldconfig similarily long. The harddrives are sata-2.
I'm running gentoo linux with kernel 2.6.38-gentoo-r1. I'm attaching the kernel config but I guess more info is needed - just let me know what is needed.
Quoted 5 lines
more than likely your problem is that barriers have been enabled for MD/DM devices on the new kernel, and they aren't on the old kernel. XFS uses barriers by default, ext3 does not. Hence XFS performance will change while ext3 will not. Check dmesg output when mounting the filesystems on the different kernels.
But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to wait for - mitigating most of the performance problems with barriers?
Signature · 7 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 _______________________________________________ xfs mailing list [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 8 lines
Quoted 4 lines
[ ... ] more than likely your problem is that barriers have been enabled for MD/DM devices on the new kernel, and they aren't on the old kernel. [ ... ]
But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to wait for - mitigating most of the performance problems with barriers?
That's an example of the 'O_PONIES' attitude: because there are no performance problems with barriers as such.
There is something completely different: a tradeoff between levels of safety (whether you want committed transactions or not and how finely grained) and time to completion.
Barriers would have performance problems if given the safety semantics they offer they could be reimplemented to give better speed, but that does not seem to be the case.
But when one sees comical "performance" comparisons without even cache flushing, explaining the difference between a performance problem and different safety/speed tradeoffs seems a bit wasted.
Again, the fundamental problem is how many committed IOPS the storage system can do given a metadata (and thus journal) intensive load (the answer is "not many" per spinning medium).
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Hi
Quoted 19 lines · Martin Steigerwald
sorry, forgot to cc.
Am Mittwoch, 27. April 2011 schrieb Dave Chinner:
Quoted 16 lines · Benjamin Schindler
Quoted 14 lines
Hi
Since upgrading to newer kernels I have serious problems with xfs performance on my root fs.
It runs on a software raid 0 with 2 disks. On the same two disks, there are two more partitions running a software raid-1 with ext3. On the ext3 system, I have no issue, so I assume the drives are fine.
But on the xfs filesystem, extracting a linux kernel archive takes 5 minutes or more, running ldconfig similarily long. The harddrives are sata-2.
I'm running gentoo linux with kernel 2.6.38-gentoo-r1. I'm attaching the kernel config but I guess more info is needed - just let me know what is needed.
Quoted 9 lines
Quoted 5 lines
more than likely your problem is that barriers have been enabled for MD/DM devices on the new kernel, and they aren't on the old kernel. XFS uses barriers by default, ext3 does not. Hence XFS performance will change while ext3 will not. Check dmesg output when mounting the filesystems on the different kernels.
But didn't 2.6.38 replace barriers by explicit flushes the filesystem has to wait for - mitigating most of the performance problems with barriers?
Well, that doesn't seem to work then may be? As always, I'm willing to do testing and provide info if required
Cheers
Benjamin
p.s. please keep the cc
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs