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.
-
-
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