Bug 1104380

Summary: Problem with tecnical depth and accuracy of documentation link provided
Product: Red Hat Enterprise Linux 6 Reporter: Umar Nadeem <unadeem>
Component: doc-Storage_Admin_GuideAssignee: Jacquelynn East <jeast>
Status: CLOSED NOTABUG QA Contact: ecs-bugs
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0CC: asriram, cwawak, dlackey, esandeen, kschneid, mhideo, nlevinki, rhs-bugs, rlandman, rwheeler, storage-doc
Target Milestone: pre-dev-freezeKeywords: Documentation
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
URL: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarrierconsider.html
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-04-15 23:46:16 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Umar Nadeem 2014-06-03 21:16:29 UTC 
User-Agent:       Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0
Build Identifier: 

escription of problem:   

The information provided in the administration guide page could be inaccurate or missing important points:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/writebarrierconsider.html 

Here are the comments of a user who used it :

"Specifically (to the best of my knowledge) a BBWC will only assure data integrity without barriers/FUA if used with the noop scheduler - with any other scheduler the filesystem transaction may be reordered posing a risk that it only an effectively random part of the operation is committed to the non-volatile storage at the time of an outage. While my understanding may be incorrect there was no information provided on the page to support any alternative hypothesis."

Reproducible: Always
Comment 3 Eric Sandeen 2014-06-24 04:09:14 UTC 
I don't think that's accurate.  The elevator code has a dispatch function which takes a "force" argument, and in that code path, i.e. CFQ has this:

/*
 * Drain our current requests. Used for barriers and when switching
 * io schedulers on-the-fly.
 */
static int cfq_forced_dispatch(struct cfq_data *cfqd)
{
        struct cfq_queue *cfqq; 
        int dispatched = 0;

        /* Expire the timeslice of the current active queue first */
        cfq_slice_expired(cfqd, 0);
        while ((cfqq = cfq_get_next_queue_forced(cfqd)) != NULL) {
                __cfq_set_active_queue(cfqd, cfqq);
                dispatched += __cfq_forced_dispatch_cfqq(cfqq);
        }

CFQ knows how to handle barriers, as far as I know.
Comment 4 Eric Sandeen 2014-06-24 13:38:53 UTC 
Sorry, the original question was about running *without* barriers.
Let me re-think this.
Comment 5 Eric Sandeen 2014-06-24 14:32:06 UTC 
As Jeff Moyer says:

> The file system will manually order dependent I/O.
> What I mean by that is the file system will send down any I/O for the
> transaction log, wait for that to complete, issue a barrier (which will
> be a noop in the case of a battery-backed write cache), and then send
> down the commit block along with another barrier.  As such, you cannot
> have the I/O scheduler reorder the commit block and the log entry with
> which it is associated.