Red Hat Bugzilla – Bug 1104380
Problem with tecnical depth and accuracy of documentation link provided
Last modified: 2015-04-15 19:46:16 EDT
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
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.
Sorry, the original question was about running *without* barriers. Let me re-think this.
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.