Hi Milan I was able to talk to Alasdair on Freenode#device-mapper and he is also of the opinion full-barrier support is the way to go. On Thu, Sep 18, 2008 at 12:27 PM, Milan Broz <mbroz@xxxxxxxxxx> wrote: > Andi's patch is not complete and I think there can be several problems with > it: > > - imagine DM device which has barrier support switched on by this simple > patch and you try to run pvmove on it. How is the barrier request processed > by underlying devices now? > > -> mapping can change online (pvmove, lvextend, lvconvert, ...) to more > complicated mapping - who reset barrier flag support? > I think these things will not create problems. > - what about stacking devices? Imagine crypto - there is one device per > table possible under linear target (where you enable barriers by this > patch). > dm-crypt will need to implement some queue flushes to properly support > barriers. Another example - partition mapping over multipath (kpartx), ... > Are you sure that is it safe with Andi's patch? > ... I do not have knowledge of dm-crypt, but yes, dm-crypt might possibly reorder. Either they should flush the queues or atleast return -EOPNOTSUPP if we need to use Andi's patch. > > It is dangerous to use that patch IMO, better not support barriers at all > here. That's why we need something more robust. > I understand the possible problems. > Unfortunately I received _no_ feedback to mentioned RFC barrier patches. Alasdair said that he will be reviewing/queueing them next week. Thanks Nikanth -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
