[Tux3] Design note: Data flush and rename ordering

[OGAWA Hirofumi]

Daniel Phillips <phillips at phunq.net> writes:

> The problem is, Ext4 holds recently written file data in cache even
> across an atomic (journalled) update of directory metadata.  While a
> strict reading of Posix permits this, application writers do not expect
> it and I think we want to define stronger semantics for Tux3.  That is,
> we should guarantee that a rename will never be committed to disk
> before the source file of the rename is flushed.
>
> Our initial implementation of atomic commit will always flush every
> dirty inode to disk at each delta transition, which provides the above
> guarantee by default.  That is, a rename will always be committed in or
> after the delta that flushes its source inode.

A bit related to this (fsync()).

	http://lkml.org/lkml/2009/3/26/72

And personally, this is one of behaviors on ext3 which I hate very much.
[the process waits the unrelated transactions to that job]
-- 
OGAWA Hirofumi <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://mailman.tux3.org/cgi-bin/mailman/listinfo/tux3