[Openstack-operators] XFS documentation seems to conflict with recommendations in Swift

[Marcelo Martins]

Hi Jonathan,


I guess that will depend on how your storage nodes are configured (hardware wise).  The reason why it's recommended is because the storage drives are actually attached to a controller that has RiW cache enabled. 



Q. Should barriers be enabled with storage which has a persistent write cache?

Many hardware RAID have a persistent write cache which preserves it across power failure, interface resets, system crashes, etc. Using write barriers in this instance is not recommended and will in fact lower performance. Therefore, it is recommended to turn off the barrier support and mount the filesystem with "nobarrier". But take care about the hard disk write cache, which should be off.


Marcelo Martins
Openstack-swift
btorch-os at zeroaccess.org

“Knowledge is the wings on which our aspirations take flight and soar. When it comes to surfing and life if you know what to do you can do it. If you desire anything become educated about it and succeed. “




On Oct 12, 2011, at 10:08 AM, Jonathan Simms wrote:

> Hello all,
> 
> I'm in the middle of a 120T Swift deployment, and I've had some
> concerns about the backing filesystem. I formatted everything with
> ext4 with 1024b inodes (for storing xattrs), but the process took so
> long that I'm now looking at XFS again. In particular, this concerns
> me http://xfs.org/index.php/XFS_FAQ#Write_barrier_support.
> 
> In the swift documentation, it's recommended to mount the filesystems
> w/ 'nobarrier', but it would seem to me that this would leave the data
> open to corruption in the case of a crash. AFAIK, swift doesn't do
> checksumming (and checksum checking) of stored data (after it is
> written), which would mean that any data corruption would silently get
> passed back to the users.
> 
> Now, I haven't had operational experience running XFS in production,
> I've mainly used ZFS, JFS, and ext{3,4}. Are there any recommendations
> for using XFS safely in production?
> _______________________________________________
> Openstack-operators mailing list
> Openstack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20111013/67d48167/attachment.html>