Re: True fsync() in Linux (on IDE)

[Chris Mason]

On Thu, 2004-03-18 at 15:46, Peter Zaitsev wrote:
> On Thu, 2004-03-18 at 12:33, Chris Mason wrote:
> 
> > Some suse 8.2 kernels had write barriers for IDE, some did not.  If
> > you're running any kind of recent suse kernel, you're doing cache
> > flushes on fsync with ext3.
> 
> I have this kernel:
> 
> 
> Linux abyss 2.4.20-4GB #1 Sat Feb 7 02:07:16 UTC 2004 i686 unknown
> unknown GNU/Linux
> 
> I believe it is reasonably  recent one from Hubert's kernels.
> 
> The thing is the performance is different if file grows or it does not.
> If it does - we have some 25 fsync/sec. IF we're writing to existing
> one, we have some 1600 fsync/sec 
> 
> In the former case cache is surely not flushed. 
> 
Hmmm, is it reiser?  For both 2.4 reiserfs and ext3, the flush happens
when you commit.  ext3 always commits on fsync and reiser only commits
when you've changed metadata.

Thanks to Jens, the 2.6 barrier patch has a nice clean way to allow
barriers on fsync, O_SYNC, O_DIRECT, etc, so we can make IDE drives much
safer than the 2.4 code did.  

I had a patch to make fsync always generate the barriers in 2.4, but it
was tricky since it had to figure out the last buffer it was going to
write before it wrote it.  The 2.6 code is much better.

> 2.4 does flush in one case but not in other. 2.6 does not do it in ether
> case.
> 
> I was also surprised to see this simple test case has so different
> performance with default and "deadline" IO scheduler   -  1.6 vs 0.5 sec
> per 1000 fsync's.

Not sure on that one, both cases are generating tons of unplugs, the
drive is just responding insanely fast.

-chris


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