xfs
[Top] [All Lists]

Re: Which FileSystem do you use on your postfix server?

Subject: Re: Which FileSystem do you use on your postfix server?
From: Justin Piszcz <jpiszcz@xxxxxxxxxxxxxxx>
Date: Fri, 31 Oct 2008 09:32:34 -0400 (EDT)
Cc: xfs@xxxxxxxxxxx
In-reply-to: <alpine.DEB.1.10.0810310810520.468@xxxxxxxxxxxxxxxx>
References: <20081031121002.D94A11F3E98@xxxxxxxxxxxxxxxxxxx> <alpine.DEB.1.10.0810310810520.468@xxxxxxxxxxxxxxxx>
User-agent: Alpine 1.10 (DEB 962 2008-03-14)


On Fri, 31 Oct 2008, Justin Piszcz wrote:



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.



No need to respond to this, sent a reply to the postfix list:

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

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