Hello, On Tue, Jan 08, 2013 at 10:04:23AM -0800, [email protected] 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
