public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Wietse Venema <wietse@porcupine.org>
Cc: Eric Sandeen <sandeen@sandeen.net>,
	Justin Piszcz <jpiszcz@lucidpixels.com>,
	Postfix users <postfix-users@postfix.org>,
	xfs@oss.sgi.com
Subject: Re: Which FileSystem do you use on your postfix server?
Date: Sat, 1 Nov 2008 09:18:17 +1100	[thread overview]
Message-ID: <20081031221817.GD19509@disturbed> (raw)
In-Reply-To: <20081031153758.EF0521F3E9E@spike.porcupine.org>

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?

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

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.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2008-10-31 22:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081031121002.D94A11F3E98@spike.porcupine.org>
2008-10-31 12:13 ` Which FileSystem do you use on your postfix server? Justin Piszcz
2008-10-31 13:32   ` Justin Piszcz
2008-10-31 14:56   ` Eric Sandeen
2008-10-31 15:37     ` Wietse Venema
2008-10-31 22:18       ` Dave Chinner [this message]
2008-10-31 22:56         ` Wietse Venema
2008-11-02 21:44           ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081031221817.GD19509@disturbed \
    --to=david@fromorbit.com \
    --cc=jpiszcz@lucidpixels.com \
    --cc=postfix-users@postfix.org \
    --cc=sandeen@sandeen.net \
    --cc=wietse@porcupine.org \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox