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 <shrin...@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@lists.openstack.org > Unsubscribe : > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack >
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
