From: Andrew Morton <akpm@digeo.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Joe Korty <joe.korty@ccur.com>,
Andreas Dilger <adilger@clusterfs.com>,
rusty@rustcorp.com.au, riel@conectiva.com.br,
linux-kernel@vger.kernel.org, hch@sgi.com
Subject: Re: 2.4.21-pre2 stalls out when running unixbench
Date: Mon, 06 Jan 2003 04:16:31 -0800 [thread overview]
Message-ID: <3E19739F.84C57EFC@digeo.com> (raw)
In-Reply-To: 1041855042.2690.2.camel@sisko.scot.redhat.com
"Stephen C. Tweedie" wrote:
>
> Hi,
>
> On Sat, 2003-01-04 at 11:11, Andrew Morton wrote:
>
> > This is because of differences in how sync() is handled between 2.4.20's
> > ext3 and 2.4.21-pre2's.
> >
> > 2.4.21-pre2:
> >
> > sync() will start the commit, and will wait on it. So you know that
> > when it returns, everything which was dirty is now tight on disk.
> >
> > So yes, running a looping sync while someone else is writing stuff
> > will take much longer in 2.4.21-pre2, because that kernel actually
> > waits on the writeout.
>
> Actually, I'm wondering if we should back that particular bit out. For
> a user with a hundred mounted filesystems, syncing each one in order,
> sequentially, is going to suck (and we don't currently have a simple way
> in 2.4 to detect which syncs are on separate spindles and so can be
> parallelised.)
>
Well personally I prefer slow-and-safe. But we could make 2.4
do what 2.5 is doing - one pass through the superblocks to start
the syncs and a second pass to wait on them all.
This is fragile stuff though....
next prev parent reply other threads:[~2003-01-06 12:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-03 16:56 2.4.21-pre2 stalls out when running unixbench Joe Korty
2003-01-03 20:07 ` Andrew Morton
2003-01-03 20:30 ` Andrew Morton
2003-01-04 1:11 ` Joe Korty
2003-01-04 11:11 ` Andrew Morton
2003-01-05 2:58 ` Joe Korty
2003-01-06 12:10 ` Stephen C. Tweedie
2003-01-06 12:15 ` John Bradford
2003-01-06 13:20 ` Stephen C. Tweedie
2003-01-06 12:16 ` Andrew Morton [this message]
2003-01-06 13:23 ` Stephen C. Tweedie
2003-01-11 8:10 ` Christoph Hellwig
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=3E19739F.84C57EFC@digeo.com \
--to=akpm@digeo.com \
--cc=adilger@clusterfs.com \
--cc=hch@sgi.com \
--cc=joe.korty@ccur.com \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@conectiva.com.br \
--cc=rusty@rustcorp.com.au \
--cc=sct@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.