lkml.org 
[lkml]   [1999]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (reiserfs) Re: Reiserfs is order of magnitude faster for fsyncof large files than ext2
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
David, I agree that you ask the right question, and I asked
<br>Yura to make the almost the same measurement you asked for
<br>5 minutes after I posted to linux-kernel about it.
<br>It shouldn't take Yura more than 30 minutes to do.
<p>Best,
<p>Hans
<p>David C Niemi wrote:
<blockquote TYPE=CITE>On Tue, 23 Feb 1999, Vladimir V. Saveliev wrote:
<br>> David C Niemi wrote:
<br>> > A question: how about fsync() when there is actually a modest amount
of
<br>> > real change between in-core and on-disk?&nbsp; The benchmark you
describe is
<br>> > really a "null fsync()", which while promising might not be completely
<br>> > representative of real-world usage.
<br>>
<br>> Hi
<br>> I would say, that the most significant thing in such test is not
amount
<br>> of changes (if you just have read whole file, fsync costs nothing,
as
<br>> all indirect blocks are in cache). The amount of un-cached indirect
<br>> blocks is the bottleneck for file system like ext2 in such test.
<p>I would expect so, but given wildly different implementations I would
be
<br>more convinced with tests showing similar results when there are a
few
<br>dirty pages.
<p>> What is typical usage pattern for fsyncing of big files of logs or
<br>> databases? 1% or 10%? We really would love to measure it.
<p>Both would be good data points, but 1% is probably much more typical.&nbsp;
If
<br>you think about it, fsync is just writing the dirty blocks that are
within
<br>the last two automatic sync() intervals worst case (sync traditionally
<br>writes all currently scheduled blocks to disk, and schedules all currently
<br>schedulable blocks, hence the merits of doing 2-3 sync commands).&nbsp;
With a
<br>sync interval of 20-30 seconds, I'd expect you would seldom dirty more
than
<br>1% of a large file within a minute unless you were in the midst of
truly
<br>torrid activity (which would be a totally separate test case).
<p>---&nbsp; David C Niemi ---niemi at tux.org---&nbsp; Reston, Virginia,
USA&nbsp; ---
<br>&nbsp; But only the man who cares about something in itself, who loves
<br>&nbsp; it and does it *con amore*, will do it in all seriousness.&nbsp;
The
<br>&nbsp; highest achievement has always been that of such men, and not
of
<br>&nbsp; the hacks who serve for pay.&nbsp; -- Arthur Schopenhauer</blockquote>

<pre>--&nbsp;
Don't be locked out of the source, and doomed to life in the slow lane.
Dump NT! Get Linux (<A HREF="http://www.kernel.org">http://www.kernel.org</A>) plus ReiserFS
&nbsp;(<A HREF="http://devlinux.org/namesys">http://devlinux.org/namesys</A>).&nbsp; If you sell an OS or
internet appliance, buy a port of ReiserFS!
Speed matters.&nbsp; Trees are fast.&nbsp; Go faster!</pre>
&nbsp;</html>
\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.026 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site