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).
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...
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.
FWIW, I don't think it's unreasonable we do this, nor does it fix all
the potential MTA problems :)
Anyhow, that patch was bogus. As soon as I get some more clues, I'll
send another one (trying to get more clueful now, not having much
success!).
--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:31 EST