Subject: Re: True  fsync() in Linux (on IDE)
From: Peter Zaitsev <peter@mysql.com>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
In-Reply-To: <20040318064757.GA1072@suse.de>
References: <1079572101.2748.711.camel@abyss.local>
	 <20040318064757.GA1072@suse.de>
Content-Type: text/plain
Organization: MySQL
Message-Id: <1079639060.3102.282.camel@abyss.local>
Mime-Version: 1.0
Date: Thu, 18 Mar 2004 11:44:21 -0800
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1426
Lines: 44

On Wed, 2004-03-17 at 22:47, Jens Axboe wrote:

> > There is solution just to disable drive write cache, but it seems to
> > slowdown performance way to much.
> 
> Chris and I have working real fsync() with the barrier patches. I'll
> clean it up and post a patch for vanilla 2.6.5-rc today.

Good to hear. How is it going to work from user point of view ? 
Just fsync working back again or there would be some special handling.

Also. What is about  fsync() in 2.6 nowadays ?

I've done some tests on 3WARE RAID array and it looks like  it is
different compared to 2.4 I've been testing previously. 

I have the simple test which has single page writes to the file followed
by fsync().   First run give you the case when file grows with each
write, second when you're writing to existing file space.

The results I have on 2.4 is something like  40 sec per 1000 fsyncs for 
new file, and 0.6 sec for existing file.

With 2.6.3 I have  both existing file and new file to complete in less
than 1 second. 


-- 
Peter Zaitsev, Senior Support Engineer
MySQL AB, www.mysql.com

Meet the MySQL Team at User Conference 2004! (April 14-16, Orlando,FL)
  http://www.mysql.com/uc2004/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/