Messages in this thread |  | | Date | Tue, 8 Jan 2013 10:45:20 -0800 | From | Tejun Heo <> | Subject | Re: [block] allow blk_flush_policy to return REQ_FSEQ_DATA independent of *FLUSH |
| |
Hello,
On Tue, Jan 08, 2013 at 10:04:23AM -0800, ajithb.kumar@gmail.com wrote: > Hi, > Could you please provide clarity on the following. > "> Hmmm... yes, this can become a correctness issue if (and only if) > > blk_queue_flush() is called to change q->flush_flags while requests > > are in-flight;" > > Could you please clarify as to why is it a correctness issue only if > blk_queue_flush() is used to change flush_flags when requests are in > flight ? As I understand, XFS does set WRITE_FLUSH_FUA flag in > _xfs_buf_ioapply() function irrespective of whether the underlying > device supports flush capabilities or not which will flow into > blk_insert_flush(). Is my reading of the code correct and is there > a general correctness issue here which potentially results in XFS > file system corruption in case of an abrupt shutdown independent of > q->flush_flags getting changed while request is in flight.
My memory is kinda fuzzy at this point but if a queue doesn't support flush, its flush_flags should be zero and generic_make_request_checks() will clear REQ_FLUSH|REQ_FUA from bio->bi_rw so we never hit blk_insert_flush() and the request will be processed as a normal IO one; however, if REQ_FLUSH goes off after a request passed generic_make_request_checks() but before blk_flush_policy(), it'll become null op and its data payload won't get written out to the underlying device, which is data corruption.
Thanks.
-- tejun
|  |