XFS questions

XFS questions

[Grozdan Nikolov]

Hi,

I have a few questions regarding the data integrity on XFS filesystems. I have 
4 servers here all running on XFS partitions and I'm a bit concerned about 
the data integrity of an XFS filesystem. After reading a lot of 
benchmarks/user experiences I came to the conclusion that XFS is really very 
fast, as I experience it here on my servers  too, but when it comes to data 
integrity it is wise not to use XFS for partitions containing important files 
as XFS may not be able to recover them after a lets say power outage. I'm 
also worried about the 'zeroing' thing in XFS. 

I have 3 questions... 

1) How reliable is XFS at data-integrity?
2) Will the 'zeroing' thing be removed/fixed in the near future?
3) Will XFS ever support ordered or journalled mode like ReiserFS or Ext3?

Thanks in advance and best regards,

Grozdan

Re: XFS questions

[Chris Wedgwood]

On Fri, Sep 08, 2006 at 07:23:07PM +0200, Grozdan Nikolov wrote:

> I'm also worried about the 'zeroing' thing in XFS.

Most of what people claim is a bit vague and often incorrect.

> 1) How reliable is XFS at data-integrity?

Fine, if your applications are sane.  MTAs like postfix for example
*never* had any problems with XFS.

> 2) Will the 'zeroing' thing be removed/fixed in the near future?

What usually happens if that if you truncate over a file, and write
data *then* loose power some of the data might not have been written
to disk yet so when you read it back the XFS returns zeroes.

This is normal/expected for journalling filesystems.  Now, by default
ext3 doesn't have this 'problem' so I think have a misconception as to
how it should work (or how they would like it to).

In recent kernels when XFS truncated over a file the data is flushed
after close() so the chances of loosing data are much less.

Why have people seen this?  Because a lot of applications do something
like:

   open file ~/.bookmarks
   read
   close

   [...]

   open file ~/.bookmarks, truncating the existing file
   write
   close

The open + truncate is journalled, so that will survive a power
failure, but the 'write' isn't --- so you might end up with a file
that looks like it has zeroes.

I'll claim this in general is a bad practise and I'm also going to
claim applications that do this ideally should be fixed to open/creat
tmp, write, fsync, close, rename tmp to original.  Not only does that
make things more reliable for XFS, but also pretty much every other fs
out there on any unix-like OS.  It also is more reliable again
something like a crash/powerfailure in the application during write
out (which I've seen).