[EMAIL PROTECTED] (Wietse Venema) writes:
> Dave Chinner:
>> 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,
>>
>> No.
>>
>> > when the file was updated after the fsync.
>>
>> and no.
>>
>> 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?
>
> This is how I hoped any reasonable implementation would work. The
> stories about null files made me wonder if there was something
> unusual about XFS that I should be aware of.
That would be
- crash + reboot + recovery before fsync() had completed
The XFS journal is metadata only, so in this crash situation, it *might*
repair the structure and pretend it had data that were lost in the
crash.
- copyback (writeback) caches (usually in hardware) that defer actually
synching data until after they acknowledge "we've hit stable storage";
for drives supporting write barriers, XFS on Linux has a pertinent
"barrier" mount option to issue write barriers to the block layer.
- HW bugs (such as drives ignoring, or reordering across, write barriers).
>> > 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.
>
> Just confirming a specific case that I care about.
>
> Here's something I would like to know regarding the order of
> directory updates:
>
> - Does fsync(file) guarantee the file's directory entry is safe?
On some file systems, fsync() used to behave like a filesystem-specific
sync().
> Some file systems complete directory updates before the open/link/rename
> system call returns, so fsync() doesn't have to worry about it.
Not typical for Linux. Recent versions have a "dirsync" mount option to
attain this behaviour, quoting Linux's man mount(8) (openSUSE 11.0 which
uses a 2.6.25 kernel):
dirsync
All directory updates within the file system should be
done synchronously. This affects the following system
calls: creat, link, unlink, symlink, mkdir, rmdir, mknod
and rename.
There is also a "dirsync" flag to chattr (D), if set on a directory,
changes to this directory are synchronous.
It depends on the file system if it heeds these. XFS on said system
at least doesn't complain.
--
Matthias Andree
