On Fri, 31 Oct 2008, Wietse Venema wrote:
Justin Piszcz:
On Fri, 31 Oct 2008, Wietse Venema wrote:
Does XFS still overwrite existing files with zeros, when those
files were open for write at the time of unclean shutdown? This
I believe this was fixed in an early 2.6.2x release, cc'ing xfs mailing
list to confirm.
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.
If there is a response you may want to repost it here (with
permission) because submissions from non-members are silently
discarded here.
Found it (fixed on May 8th 2008):
http://oss.sgi.com/projects/xfs/faq.html#nulls
Q: Why do I see binary NULLS in some files after recovery when I unplugged the
power?
Update: This issue has been addressed with a CVS fix on the 29th March 2007 and
merged into mainline on 8th May 2007 for 2.6.22-rc1.
XFS journals metadata updates, not data updates. After a crash you are supposed
to get a consistent filesystem which looks like the state sometime shortly
before the crash, NOT what the in memory image looked like the instant before
the crash.
Since XFS does not write data out immediately unless you tell it to with fsync,
an O_SYNC or O_DIRECT open (the same is true of other filesystems), you are
looking at an inode which was flushed out, but whose data was not. Typically
you'll find that the inode is not taking any space since all it has is a size
but no extents allocated (try examining the file with the xfs_bmap(8) command).
--
Justin.
