On Tue, Aug 09 2011 at 1:51pm -0400, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, > > On Tue, Aug 09, 2011 at 01:43:47PM -0400, Mike Snitzer wrote: > > [cc'ing dm-devel] > > > > All of these issues have come to light because DM was not setting > > flush_flags based on the underlying device(s). Now fixed in v3.1-rc1: > > ed8b752 dm table: set flush capability based on underlying devices > > > > Given that commit, and that request-based DM is beneath the elevator, it > > seems any additional effort to have DM flushes re-enter the flush > > machinary is unnecessary. > > Hmmm... what if the underlying devices have different featureset? Use > the lowest common denominator? Yes, for DM, if any device in the stack requires FLUSH/FUA then the upper request_queue's flush_flags will be set to reflect that. Bio-based DM _could_ end up issuing a flush to a device that doesn't need the flush. But once the bio emerges from the bottom of the bio-based stack it'll get handed to the flush mechanism where it'll be dropped. Bio-based DM may stack ontop of request-based DM (think LVM ontop of mpath device). Request-based DM may _not_ stack on bio-based DM. Request-based DM, the cause of all this discussion, is only used for the multipath target and I'm not aware of any plans to provide more complex stacking via request-based DM. Doing so would require splitting a request that spans target boundaries, etc. So we're left with request-based DM only allowing a single target, meaning: even if request-based DM were stacked a couple times the flush_flags would still reflect the underlying physical device's queue. > The flush mechanism is designed to > deal with stacking by going through flush at each level. Stacking > queue can simply export support for both REQ_FLUSH and FUA and the > lower lever queue will decompose them according to the capability > supported by the actual device. > > IIUC, what's broken here is some insert functions aren't using > ELEVATOR_INSERT_FLUSH when needed and there are some issues due to the > special nature of the stacked requests which I think should be fixed. OK, conceptually pure, just seems the fixes are multiplying. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
