From: "Stephen C. Tweedie" <sct@redhat.com>
To: Andrew Morton <akpm@zip.com.au>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>,
Alexander Moibenko <moibenko@fnal.gov>,
linux-kernel@vger.kernel.org, Stephen Tweedie <sct@redhat.com>
Subject: Re: fsync delays for a long time.
Date: Fri, 15 Feb 2002 16:48:09 +0000 [thread overview]
Message-ID: <20020215164809.A5074@redhat.com> (raw)
In-Reply-To: <3C6C2342.5044B738@zip.com.au> <E16bT7y-00017B-00@the-village.bc.nu> <3C6C2A39.38ED19B1@zip.com.au>
In-Reply-To: <3C6C2A39.38ED19B1@zip.com.au>; from akpm@zip.com.au on Thu, Feb 14, 2002 at 01:20:57PM -0800
Hi,
On Thu, Feb 14, 2002 at 01:20:57PM -0800, Andrew Morton wrote:
> I'm surprised. ext2's fsync in 2.2 is in fact quite optimal: a single
> pass across the block tree, in probable-LBA-order.
Except that it pages the entire indirect tree into memory, which is
_really_ painful if you're just appending to the end of a 1GB file.
See ext2_sync_file(): in 2.2 it uses the indirect tree to locate all
possible buffer_heads which might need flushing, and then it does a
buffer cache lookup for every block in the file. It's _way_
suboptimal for large files, just in terms of the CPU cost and memory
cost of maintaining and walking the block tree.
2.4 doesn't need to search physically for dirty buffers, so is much
much faster.
Cheers,
Stephen
next prev parent reply other threads:[~2002-02-15 16:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-14 16:03 fsync delays for a long time Alexander Moibenko
2002-02-14 17:39 ` Alan Cox
2002-02-14 20:51 ` Andrew Morton
2002-02-14 21:09 ` Alan Cox
2002-02-14 21:12 ` Alexander Moibenko
2002-02-14 21:37 ` Alan Cox
2002-02-14 21:26 ` Alexander Moibenko
2002-02-14 21:41 ` Andrew Morton
2002-02-14 22:18 ` Alexander Moibenko
2002-02-14 21:20 ` Andrew Morton
2002-02-14 21:38 ` Alan Cox
2002-02-15 16:48 ` Stephen C. Tweedie [this message]
2002-02-15 17:24 ` Simon Kirby
2002-02-15 19:07 ` Andrew Morton
2002-02-15 19:21 ` Simon Kirby
2002-02-17 12:47 ` Bill Davidsen
2002-02-17 16:45 ` Simon Kirby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020215164809.A5074@redhat.com \
--to=sct@redhat.com \
--cc=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=moibenko@fnal.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox