On Thu, 11 Oct 2007 11:01:39 +1000, David Chinner wrote:

 
quoted text
> Latencies are an order of magnitude lower at 60-70ms because the disks
> have less deep queues. This is expected - deep queues and multiple
> outstanding I/Os are the enemy of single I/O latency....
> 
> If I remount with barriers enabled, the latency at nr_requests=128
> goes up to a consistent 2.2s. Not surprising, we're flushing the drive
> cache very regularly now and it points to the create or truncate
> transaction having to pushing log buffers to disk. The latency remains
> at 70-80ms at nr_requests=4.

Thanks for the info. I did try fiddling nr_requests but I made it
bigger. I'll try with it lower.
 
quoted text
> > It seems this problem was introduced between 2.6.18 and 2.6.19. 
> 
> When the new SATA driver infrastructure was introduced. Do you have
> NCQ enabled on more recent kernels and not on 2.6.18? If so, try
> disabling it and see if the problem goes away....

Unfortunately the drives in the file server don't support NCQ. Not sure
if it's supported in the machine I was testing on (it's certainly a few
years old).
 
quoted text
> > The other thing I've found is that if I do the dd to an ext3 fs (on
> > the same disk at least) while running the test in the XFS fs then I
> > also see the latencies.
> 
> So it's almost certainly pointing at an elevator or driver change, not
> an XFS change.

OK, though it doesn't seem to effect ext3. I'm going to run a git
bisect to see what it comes up with.

quoted text
> Cheers,
> 
> dave.

Cheers,

Andrew
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html