Frank Cusack wrote:
On 1/31/11 5:23 PM +0000 Ron Leach wrote:
Further, the NFS shares can be mounted on the client with a 'sync' option
that forces physical writes before returning to the caller. Though this
would be horrifically slow in any high load (network transmission times,
disc io queues etc), in our situation of low load we could consider using
this option to minimise the potential for email loss due to crash or
power fail.
Unless I'm wrong about something here, I think this closes the
NFS-related concern about XFS and Dovecot and loss of email.
You're wrong.
Yes, NFS semantics "guarantee" commit, but what happens is that the
underlying filesystem (e.g. ext3, xfs with metadata spooling) lies to
the kernel about what has been committed. The NFS call returns, but
the data has not actually been committed. There have even been
NFS server tweaks for some implementations that themselves lie to
the client, ie w/o depending on filesystem lies, for performance
reasons.
Oh, dear.
So does that mean we're lost, having built these XFS data servers? Is
XFS, then, the 'wrong' choice for email integrity across crashes and
power fail, even when using NFS in low load systems?
Fortunately, these two machines are only being used for backup at the
moment - we haven't migrated the application 'live' data stores - yet.
So we could rebuild them. With ZFS, maybe.
All we want to do is not lose emails.
What does everyone else do? Lose emails?
regards, Ron
