On Fri, Oct 31, 2008 at 11:37:58AM -0400, Wietse Venema wrote:
> Eric Sandeen:
> > > This
> > > would violate a basic requirement of Postfix (don't lose data after
> > > fsync). Postfix updates existing files all the time: it updates
> > > queue files as it marks recipients as done, and it updates mailbox
> > > files as it appends mail.
> > As long as postfix is looking after data properly with fsyncs etc, xfs
> > should be perfectly safe w.r.t. data integrity on a crash. If you see
> > any other behavior, it's a *bug* which should be reported, and I'm sure
> > it would be fixed. As far as I know, though, there is no issue here.
> The specific question is, will unclean shutdown cause loss of data
> that was already fsynced,
> when the file was updated after the fsync.
XFS guarantees that you won't lose anything you fsync()d. You might
lose what you wrote after the fsync()), though, because you haven't
fsync()d it. Obvious, yes?
> For example, if the on-disk file metadata is updated after the file
> data is appended, then there is no need to have a zero-fill problem
> after crash during append.
In case you didn't read Eric's response - that's exactly how we
fixed XFS to prevent this problem. And please stop propagating
this erroneous "zero-fill" meme - Eric addressed how wrong that
FUD is as well.
> What if the crash happens after Postfix requests a 1-byte write in
> the middle of a file, i.e. without changing the size? A
> reasonable implementation would not corrupt the file, but would
> either update the file data or not change it. I can deal with
That is exactly how XFS has always behaved for non-extending data
overwrite. i.e. Exactly the same pretty much every filesystem that
has ever existed.