Open Stack

Well the short answer to that question is that it is generally a best
practice to run a disk controller card  with a persistent cache in front of
your storage drives.  When this is the case you want to turn barriers off,
otherwise they would render your cache ineffective.

If you are not running a disk controller with persistent cache, then
generally, you want to turn barriers on, but the performance is likely to
be horrible.  We could also get into a discussion of weather your
controller and drives actually honor the barriers, and things just start to
get messy. :)

--
Chuck


On Mon, Apr 21, 2014 at 1:13 PM, Shrinand Javadekar <shrinand at maginatics.com
> wrote:

> Hi,
>
> I notice that the recommended way of deploying Swift is to use XFS on
> the storage nodes. This XFS volume is mounted using the "nobarriers"
> option.
>
> If I'm not wrong, Swift does an fsync after every put to make sure
> that the object is written to disk. But in the absence of barriers
> this isn't guaranteed, correct? Based on the documentation [1], it
> seems that the storage device might declare that the data was
> persisted, but actually might just be holding it in it's own cache.
>
> How does Swift then guarantee data persistence in case there is a
> power outage on the storage nodes?
>
> Also, without barriers, the writes might get ordered differently when
> being written to disk. If there are multiple versions of the same
> object in cache it is required that they be written in order. How does
> Swift deal with this?
>
> Thanks in advance.
> -Shri
>
> [1]
> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/ch-writebarriers.html
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140422/13e603e3/attachment.html>