Messages in this thread | | | From | Martin Steigerwald <> | Subject | Re: Linux 2.6.29 | Date | Fri, 27 Mar 2009 12:27:01 +0100 |
| |
Am Mittwoch 25 März 2009 schrieb Jesse Barnes: > On Tue, 24 Mar 2009 09:20:32 -0400 > > Theodore Tso <tytso@mit.edu> wrote: > > They don't solve the problem where there is a *huge* amount of writes > > going on, though --- if something is dirtying pages at a rate far > > greater than the local disk can write it out, say, either "dd > > if=/dev/zero of=/mnt/make-lots-of-writes" or a massive distcc cluster > > driving a huge amount of data towards a single system or a wget over > > a local 100 megabit ethernet from a massive NFS server where > > everything is in cache, then you can have a major delay with the > > fsync(). > > You make it sound like this is hard to do... I was running into this > problem *every day* until I moved to XFS recently. I'm running a > fairly beefy desktop (VMware running a crappy Windows install w/AV junk > on it, builds, icecream and large mailboxes) and have a lot of RAM, but > it became unusable for minutes at a time, which was just totally > unacceptable, thus the switch. Things have been better since, but are > still a little choppy. > > I remember early in the 2.6.x days there was a lot of focus on making > interactive performance good, and for a long time it was. But this I/O > problem has been around for a *long* time now... What happened? Do not > many people run into this daily? Do all the filesystem hackers run > with special mount options to mitigate the problem?
Well I always had the feeling that somewhen from one 2.6.x to another I/O latencies increased a lot. But first I thought I was just imaging this and when I more and more thought that this is for real, I forgot since when I observed these increased latencies.
This is on IBM ThinkPad T42 and T23 with XFS.
I/O latencies are pathetic when dpkg reads in the database or I do tar -xf linux-x.y.z.tar.bz2.
I never got down to what is causing these higher latencies though also I tried different I/O schedulers, tuned XFS options, used relatime.
What I found tough is that on XFS at least a tar -xf linux-kernel / rm -rf linux-kernel operation is way slower with barriers and write cache enabled that with no barriers and no write cache enabled. And frankly I never got that.
XFS crawls to a stop on metadata operations when barriers are enabled. According to the XFS FAQ disabling drive write cache should be as safe as enabling barriers. And I always unterstood barriers as a feature to be have *some* ordering contraints, i.e. write before barrier go before barrier and writes after it after it - even when a drives hardware write cache is involved. But when this cache is enabled ordering will always be like issued from Linux block layer cause all I/Os issued to the drive are write-through and synchron without write cache, versus only barrier requests are synchron with barriers and write cache.
-- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 [unhandled content-type:application/pgp-signature] | |