Re: Directory fsync

[Zhu Han <schumi.han@xxxxxxxxx>]

On Sat, Sep 24, 2011 at 7:09 AM, Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx> wrote:

On Freitag, 23. September 2011 Christoph Hellwig wrote:
> As far as standards are concerned it is.  As far as the current XFS
> implementation is concerned you don't need it as the file fsync will
> also force out all transactions that belong to the create.

Aren't you giving O_PONIES to the users? ;-)

I understand your description, but we should always tell people to use a
directory fsync to be sure. Their applications might run on other
filesystems, or run for 10 years, and maybe XFS's implementation changes
in between. And maybe in historical kernels even XFS's implementation
wasn't like it's now?

Thank you all.

I see the importance of following the standard. But I am glad to know the current implementation of XFS enforce more strict fsync semantic, just as every application developer wishes.

What I worry is not much applications syncs the directory after new files are created, even if PostgreSQL[1] and many other NoSQL database.  If the current implementation forces more strict semantic, it makes our mind much much more peaceful.

And , not many runtime supports sync of directory, e.g. java ecosystem does not have such support... So it is very very hard to follow this standard.

For God's sake, the right semantic of fsync should be "The users wants to assure the file is retrievable after system crash or power failure if fsync returned successfully". 

[1]  http://postgresql.1045698.n5.nabble.com/fsync-reliability-td4330289.html

@schumi: If your application should be able to run in a safe way on
other filesystems, or other kernel releases, or other unixes, it's best
to fsync the directory inode too. It's better to use it always, then
nothing won't break.

--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc

it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531

// Haus zu verkaufen: http://zmi.at/langegg/