Directory fsync

[Zhu Han]

On Sat, Sep 24, 2011 at 7:09 AM, Michael Monnerie <
michael.monnerie at is.it-management.at> 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110924/d492c623/attachment.htm>