From: Andrew Morton <akpm@zip.com.au>
To: Chris Wedgwood <cw@f00f.org>
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org, Alan Cox <alan@lxorguk.ukuu.org.uk>,
Chris Mason <mason@suse.com>
Subject: Re: [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semantic change patch)
Date: Fri, 03 Aug 2001 18:45:13 -0700 [thread overview]
Message-ID: <3B6B53A9.A9923E21@zip.com.au> (raw)
In-Reply-To: <01080315090600.01827@starship> <Pine.GSO.4.21.0108031400590.3272-100000@weyl.math.psu.edu> <9keqr6$egl$1@penguin.transmeta.com>, <9keqr6$egl$1@penguin.transmeta.com> <20010804100143.A17774@weta.f00f.org> <3B6B4B21.B68F4F87@zip.com.au>, <3B6B4B21.B68F4F87@zip.com.au> <20010804131904.E18108@weta.f00f.org>
Chris Wedgwood wrote:
>
> On Fri, Aug 03, 2001 at 06:08:49PM -0700, Andrew Morton wrote:
>
> Ow. You just crippled ext3.
>
> How so? The Flush all transactions on fsync behaviour that resierfs
> did/does have at present too? (There are 'fixes' to reiserfs for
> this).
That, plus the fact that ext3 gets its synchronous-op scalability
from batching the transactions from multiple threads together.
The holding of parent->parent->i_sem across synchronous writes could
defeat that.
ext3 does physical, block-level journalling. (its journalling layer is
actually designed to be fs-independent so one could journal other filesystems
with it). So there is no tracking between a particular fs event and a
particular transaction. A transaction is just a blob of blocks which
can encompass thousands of fs events.
> I don't think an ext2 problem (which I don't think is a problem at
> all) should be "fixed" at the VFS layer when other filesystems are
> perfectly happy without it, no?
>
> If you want to be sure that when you fsync a file, that, silly bugger
> rename games further up the path aside, the entire path is also on
> disk, the VFS is the only place to do it with the current fs API.
>
> really, there is _some_ merit in the argument that
>
> open
> fsync
> close
> <crash>
>
> shouldn't loose the file...
Agreed - I think it's the expected and sensible behaviour. But I've seen
no complaints about it except for use in a few specialised applications.
Where "a few" == "one", actually.
> This whole thread, talking about "linux this" and "linux that" is
> off-base. It's ext2 we're talking about. This MTA requirement is
> a highly unusual and specialised thing - I don't see why the
> general-purpose ext2 should bear the burden of supporting it when
> other filesystems such as reiserfs (I think?) and ext3 support it
> naturally and better than ext2 ever will.
>
> Well, since it will only sync dirty blocks, it will hardly hurt ext2
> that much at all --- and it will only force the dirty blocks in path
> components to be written when you fsync the file, thats probably only
> a single block anyhow.
mmm... Holding i_sem across multiple revs of the disk will hurt. It
doesn't *need* to be held while we're waiting on IO, but fixing that
would be a big change, and there has been little motivation to change
things because it is for specialised apps.
-
next prev parent reply other threads:[~2001-08-04 1:39 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <0108030507330F.00440@starship>
[not found] ` <Pine.GSO.4.21.0108022312211.1494-100000@weyl.math.psu.edu>
2001-08-03 13:09 ` intermediate summary of ext3-2.4-0.9.4 thread Daniel Phillips
2001-08-03 14:43 ` Horst von Brand
2001-08-03 17:49 ` Mike Castle
2001-08-04 3:23 ` Daniel Phillips
2001-08-03 18:08 ` Alexander Viro
2001-08-03 18:26 ` Daniel Phillips
2001-08-03 18:53 ` Alexander Viro
2001-08-03 20:50 ` Daniel Phillips
2001-08-04 3:43 ` Matthias Andree
2001-08-03 18:34 ` Linus Torvalds
2001-08-03 22:01 ` [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semantic change patch) Chris Wedgwood
2001-08-03 22:33 ` Alexander Viro
2001-08-03 23:16 ` Chris Wedgwood
2001-08-03 23:23 ` Alexander Viro
2001-08-04 3:53 ` Matthias Andree
2001-08-04 5:48 ` Alexander Viro
2001-08-03 22:45 ` Alexander Viro
2001-08-03 23:09 ` Chris Wedgwood
2001-08-03 23:15 ` Alexander Viro
2001-08-03 23:20 ` Chris Wedgwood
2001-08-03 23:25 ` Alexander Viro
2001-08-03 23:35 ` Chris Wedgwood
2001-08-03 23:41 ` Alexander Viro
2001-08-03 23:46 ` Chris Wedgwood
2001-08-03 23:53 ` Alexander Viro
2001-08-04 7:45 ` [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semanticchange patch) Hans Reiser
2001-08-04 18:31 ` Chris Wedgwood
2001-08-05 1:47 ` Alexander Viro
2001-08-08 17:22 ` [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semanticchangepatch) Hans Reiser
2001-08-03 23:42 ` [PATCH] 2.4.8-pre3 fsync entire path (+reiserfs fsync semantic change patch) Alan Cox
2001-08-03 23:44 ` Chris Wedgwood
2001-08-04 1:08 ` Andrew Morton
2001-08-04 1:19 ` Chris Wedgwood
2001-08-04 1:45 ` Andrew Morton [this message]
2001-08-04 4:04 ` Matthias Andree
2001-08-04 18:30 ` Chris Wedgwood
2001-08-05 12:15 ` Matthias Andree
2001-08-05 12:32 ` Chris Wedgwood
2001-08-05 13:02 ` Matti Aarnio
2001-08-04 21:07 ` Andrew Morton
2001-08-04 21:07 ` Andrew Morton
2001-08-05 7:25 ` Chris Wedgwood
2001-08-09 13:25 ` Matthias Andree
2001-08-04 17:35 ` Jan Harkes
2001-08-04 18:18 ` Chris Wedgwood
2001-08-06 15:02 ` Chris Mason
2001-08-06 20:48 ` Chris Wedgwood
2001-08-03 22:29 ` Anton Altaparmakov
2001-08-03 23:06 ` Chris Wedgwood
2001-08-06 15:23 ` looking for resources for designing loopback filesystem dave-mlist
2001-08-06 16:11 ` Ville Herva
2001-08-03 18:36 ` intermediate summary of ext3-2.4-0.9.4 thread Matthias Andree
2001-08-03 19:16 ` Alexander Viro
2001-08-04 3:40 ` fdatasync(2) is also there (was: intermediate summary of ext3-2.4-0.9.4 thread) Matthias Andree
2001-08-05 0:28 ` Mike Castle
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=3B6B53A9.A9923E21@zip.com.au \
--to=akpm@zip.com.au \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cw@f00f.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mason@suse.com \
--cc=torvalds@transmeta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).