David, I agree that you ask the right question, and I asked
Yura to make the almost the same measurement you asked for
5 minutes after I posted to linux-kernel about it.
It shouldn't take Yura more than 30 minutes to do.
Best,
Hans
David C Niemi wrote:
> On Tue, 23 Feb 1999, Vladimir V. Saveliev wrote:
> > David C Niemi wrote:
> > > A question: how about fsync() when there is actually a modest amount of
> > > real change between in-core and on-disk? The benchmark you describe is
> > > really a "null fsync()", which while promising might not be completely
> > > representative of real-world usage.
> >
> > Hi
> > I would say, that the most significant thing in such test is not amount
> > of changes (if you just have read whole file, fsync costs nothing, as
> > all indirect blocks are in cache). The amount of un-cached indirect
> > blocks is the bottleneck for file system like ext2 in such test.
>
> I would expect so, but given wildly different implementations I would be
> more convinced with tests showing similar results when there are a few
> dirty pages.
>
> > What is typical usage pattern for fsyncing of big files of logs or
> > databases? 1% or 10%? We really would love to measure it.
>
> Both would be good data points, but 1% is probably much more typical. If
> you think about it, fsync is just writing the dirty blocks that are within
> the last two automatic sync() intervals worst case (sync traditionally
> writes all currently scheduled blocks to disk, and schedules all currently
> schedulable blocks, hence the merits of doing 2-3 sync commands). With a
> sync interval of 20-30 seconds, I'd expect you would seldom dirty more than
> 1% of a large file within a minute unless you were in the midst of truly
> torrid activity (which would be a totally separate test case).
>
> --- David C Niemi ---niemi at tux.org--- Reston, Virginia, USA ---
> But only the man who cares about something in itself, who loves
> it and does it *con amore*, will do it in all seriousness. The
> highest achievement has always been that of such men, and not of
> the hacks who serve for pay. -- Arthur Schopenhauer
-- Don't be locked out of the source, and doomed to life in the slow lane. Dump NT! Get Linux (http://www.kernel.org) plus ReiserFS (http://devlinux.org/namesys). If you sell an OS or internet appliance, buy a port of ReiserFS! Speed matters. Trees are fast. Go faster!
--------------DC73A0022AF7A72F5E57A917 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> David, I agree that you ask the right question, and I asked
Yura to make the almost the same measurement you asked for
5 minutes after I posted to linux-kernel about it.
It shouldn't take Yura more than 30 minutes to do.Best,
Hans
David C Niemi wrote:
On Tue, 23 Feb 1999, Vladimir V. Saveliev wrote:
> David C Niemi wrote:
> > A question: how about fsync() when there is actually a modest amount of
> > real change between in-core and on-disk? The benchmark you describe is
> > really a "null fsync()", which while promising might not be completely
> > representative of real-world usage.
>
> Hi
> I would say, that the most significant thing in such test is not amount
> of changes (if you just have read whole file, fsync costs nothing, as
> all indirect blocks are in cache). The amount of un-cached indirect
> blocks is the bottleneck for file system like ext2 in such test.I would expect so, but given wildly different implementations I would be
more convinced with tests showing similar results when there are a few
dirty pages.> What is typical usage pattern for fsyncing of big files of logs or
> databases? 1% or 10%? We really would love to measure it.Both would be good data points, but 1% is probably much more typical. If
you think about it, fsync is just writing the dirty blocks that are within
the last two automatic sync() intervals worst case (sync traditionally
writes all currently scheduled blocks to disk, and schedules all currently
schedulable blocks, hence the merits of doing 2-3 sync commands). With a
sync interval of 20-30 seconds, I'd expect you would seldom dirty more than
1% of a large file within a minute unless you were in the midst of truly
torrid activity (which would be a totally separate test case).--- David C Niemi ---niemi at tux.org--- Reston, Virginia, USA ---
But only the man who cares about something in itself, who loves
it and does it *con amore*, will do it in all seriousness. The
highest achievement has always been that of such men, and not of
the hacks who serve for pay. -- Arthur Schopenhauer-- Don't be locked out of the source, and doomed to life in the slow lane. Dump NT! Get Linux (http://www.kernel.org) plus ReiserFS (http://devlinux.org/namesys). If you sell an OS or internet appliance, buy a port of ReiserFS! Speed matters. Trees are fast. Go faster!--------------DC73A0022AF7A72F5E57A917-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/