Open Stack

I see. Thanks Chuck!

On Tue, Apr 22, 2014 at 7:20 AM, Chuck Thier <cthier at gmail.com> wrote:
> 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
>
>