On Wed, 2016-06-22 at 18:38 -0400, Mike Snitzer wrote: > On Wed, Jun 22 2016 at 4:16P -0400, > Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote: > > > > On Wed, 2016-06-22 at 12:15 -0700, Dan Williams wrote: > > > > > > On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu <toshi.kani@xxxxxxx> > > > wrote: > > > > > > > > On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote: > > > > > > > > > > On Tue, Jun 21 2016 at 11:44am -0400, > > > > > Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote: > > > > > > > > > > > > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > > > > > > > > > The devices in question have a request_queue. All bio-based device > > > > > have a request_queue. > > > > > > > > DAX-capable devices have two operation modes, bio-based and DAX. I > > > > agree that bio-based operation is associated with a request queue, and > > > > its capabilities should be set to it. DAX, on the other hand, is > > > > rather independent from a request queue. > > > > > > > > > > > > > > I don't have a big problem with GENHD_FL_DAX. Just wanted to point > > > > > out that such block device capabilities are generally advertised in > > > > > terms of a QUEUE_FLAG. > > > > > > > > I do not have a strong opinion, but feel a bit odd to associate DAX to > > > > a request queue. > > > > > > Given that we do not support dax to a raw block device [1] it seems a > > > gendisk flag is more misleading than request_queue flag that specifies > > > what requests can be made of the device. > > > > > > [1]: acc93d30d7d4 Revert "block: enable dax for raw block devices" > > > > Oh, I see. I will change to use request_queue flag. > > I implemented the block patch for this yesterday but based on your > feedback I stopped there (didn't carry the change through to the DM core > and DM linear -- can easily do so tomorrow though). > > Feel free to use this as a starting point and fix/extend and add a > proper header: Thanks Mike! I made similar changes as well. I will take yours and finish up the rest. :) -Toshi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
