I see. Thanks Chuck! On Tue, Apr 22, 2014 at 7:20 AM, Chuck Thier <[email protected]> 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 > <[email protected]> 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 : [email protected] >> Unsubscribe : >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack > >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
