On Tue, 2016-06-21 at 09:34 -0600, Kani, Toshimitsu wrote: > On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote: > > > > On Mon, Jun 20 2016 at 6:22pm -0400, > > Mike Snitzer <snitzer@xxxxxxxxxx> wrote: > > > > > > On Mon, Jun 20 2016 at 5:28pm -0400, > > > Kani, Toshimitsu <toshi.kani@xxxxxxx> wrote: > > > > : > > > > > > Looks good, I folded it in and tested it to work. Pushed to my 'wip' > > > branch. > > > > > > No longer seeing any corruption in my test that was using partitions > > > to span pmem devices with a dm-linear device. > > > > > > Jens, any chance you'd be open to picking up the first 2 patches in > > > this series? Or would you like to see them folded or something > > > different? > > > > I'm now wondering if we'd be better off setting a new QUEUE_FLAG_DAX > > rather than establish GENHD_FL_DAX on the genhd? > > > > It'd be quite a bit easier to allow upper layers (e.g. XFS and ext4) to > > check for a queue flag. > > I think GENHD_FL_DAX is more appropriate since DAX does not use a request > queue, except for protecting the underlining device being disabled while > direct_access() is called (b2e0d1625e19). Forgot to mention that there are bdev_dax_supported() and bdev_dax_capable() interfaces that can be called from upper layers. They both call bdev_direct_access() which checks GENHD_FL_DAX. Thanks, -Toshi > About protecting direct_access, this patch assumes that the underlining > device cannot be disabled until dtr() is called. Is this correct? If > not, I will need to call dax_map_atomic(). > > Thanks, > -Toshi -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
