xfs
[Top] [All Lists]

Re: HUGE XFS regression in 2.6.32 upto 2.6.38

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: HUGE XFS regression in 2.6.32 upto 2.6.38
From: Raz <raziebe@xxxxxxxxx>
Date: Tue, 12 Apr 2011 14:19:43 +0300
Cc: xfs-oss <xfs@xxxxxxxxxxx>
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=M1z8g57VF0F29n4YFT4h6um8BsOQ+50AUonJRi6sb3k=; b=PCFzmN/jc61vDhubgA4U+kr2OkukTzljAYXXSWNTrI0pY/djD48HByzB9FSouJhvcK kV+femq7zv0BZ4uAs79+CMPt/OX0QJI2YWBeCnXE78XO5P5+ykEUCJ6QvF7iSPXwiDb6 nEmm5OtPVImFbTVy//EQcUdreDhpDa3KTJs0E=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=T6x9fWSTfNXEIk0JmJ7wuyI1oX0UTP4kiOUAEyKO72sx6cMMr5svTqnLo0jN+cPKFe 5F6Kf0oxoo4GvA7x+Tq3L7k7jnitdGwXTy3wuFjPwbfzrixnWvA7o62L9+jE0h4YhVXe 6VxU2LT71VR1/lkeNrVvSHVtTdtbb1X8zOip0=
In-reply-to: <20110412095233.GZ31057@dastard>
References: <BANLkTinyBD7Zm3DvoYCVfYJkF36yXz6hOA@xxxxxxxxxxxxxx> <20110412095233.GZ31057@dastard>
you are correct. man page says "..untill data has been physically
written to the underlying storage".
missed that one.

thank you dave

On Tue, Apr 12, 2011 at 12:52 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Tue, Apr 12, 2011 at 10:58:53AM +0300, Raz wrote:
>> Christoph Hello
>> I am testing 2.6.38 with AIM benchmark.
>> I compared 2.6.38 to 2.6.27 and I noticed that 2.6.27 is much better
>> than 2.6.38 hwhen
>> doing sync random writes test over an xfs regular file over native
>> Linux partition on top common sata disk.
>> I git bisected the problem and I reached this SHA1:
>> commit 13e6d5cdde0e785aa943810f08b801cadd0935df
>> Author: Christoph Hellwig <hch@xxxxxx>
>> Date:   Mon Aug 31 21:00:31 2009 -0300
>>
>>    xfs: merge fsync and O_SYNC handling
>>
>>    The guarantees for O_SYNC are exactly the same as the ones we need to
>>    make for an fsync call (and given that Linux O_SYNC is O_DSYNC the
>>    equivalent is fdadatasync, but we treat both the same in XFS), except
>>    with a range data writeout.  Jan Kara has started unifying these two
>>    path for filesystems using the generic helpers, and I've started to
>>    look at XFS.
>> ...
>>
>>
>> The bellow two tests presents the how different performance is before and 
>> patch:
>> #test 16) bisect 11
>> ------------------------------------------------------------------------------------------------------------
>>  Test        Test        Elapsed  Iteration    Iteration          Operation
>> Number       Name      Time (sec)   Count   Rate (loops/sec)    Rate 
>> (ops/sec)
>> ------------------------------------------------------------------------------------------------------------
>>     1 sync_disk_rw        30.71         19    0.61869         1583.85
>> Sync Random Disk Writes (K)/second
>> ------------------------------------------------------------------------------------------------------------
>
> That's clearly showing that your sync writes are not hitting the
> disk. IOWs, the sync writes are not synchronous at all. There is
> no way a single SATA drive can do >1500 writes to stable storage
> per second.
>
> IOWs, before this fix, sync writes were broken on your hardware.
>
>> #test 17 ) bisect 12
>> ------------------------------------------------------------------------------------------------------------
>>     1 sync_disk_rw        69.05          1    0.01448           37.07
>> Sync Random Disk Writes (K)/second
>> ------------------------------------------------------------------------------------------------------------
>
> And that's pretty tpyical for a SATA drive where sync writes are
> actually hitting the platter correctly.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@xxxxxxxxxxxxx
>

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