xfs
[Top] [All Lists]

Re: Directory fsync

To: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Subject: Re: Directory fsync
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 26 Sep 2011 10:28:11 +1000
Cc: xfs@xxxxxxxxxxx, Christoph Hellwig <hch@xxxxxxxxxxxxx>, Zhu Han <schumi.han@xxxxxxxxx>
In-reply-to: <201109240109.45532@xxxxxx>
References: <CAF7KpS8h2KDsLVzwAj=5ig-yuuiCwjQSVk0Nfy9UJ0qiyAqeCQ@xxxxxxxxxxxxxx> <20110923163354.GA24319@xxxxxxxxxxxxx> <201109240109.45532@xxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Sat, Sep 24, 2011 at 01:09:44AM +0200, Michael Monnerie 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?

XFS's journalling has always behaved this way - *all* transactions
prior to the fsync() triggered log force are guaranteed to be on
disk once the fsync completes. There are no plans to change this
behaviour, either, because we rely on this architectural
characteristic to provide strong ordering of metadata operations in
many places.

All it means is that the directory fsync() is a no-op that only
costs CPU time.

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

*nod*

Cheers,

Dave.
-- 
Dave Chinner
david@xxxxxxxxxxxxx

<Prev in Thread] Current Thread [Next in Thread>