From: Mike Snitzer <snitzer@redhat.com> To: "Kani, Toshimitsu" <toshi.kani@hpe.com> Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "sandeen@redhat.com" <sandeen@redhat.com>, "linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>, "agk@redhat.com" <agk@redhat.com>, "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "axboe@kernel.dk" <axboe@kernel.dk>, "axboe@fb.com" <axboe@fb.com>, "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>, "dm-devel@redhat.com" <dm-devel@redhat.com> Subject: Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Date: Wed, 22 Jun 2016 18:38:42 -0400 [thread overview] Message-ID: <20160622223842.GA34512@redhat.com> (raw) In-Reply-To: <1466625958.3504.340.camel@hpe.com> On Wed, Jun 22 2016 at 4:16P -0400, Kani, Toshimitsu <toshi.kani@hpe.com> 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@hpe.com> > > 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@hpe.com> 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@redhat.com> wrote: > > > > > > 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). > > > > > > > > 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: From e88736ce322f248157da6c7d402e940adafffa1e Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer@redhat.com> Date: Tue, 21 Jun 2016 12:23:29 -0400 Subject: [PATCH] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support Signed-off-by: Mike Snitzer <snitzer@redhat.com> --- drivers/block/brd.c | 3 +++ drivers/nvdimm/pmem.c | 1 + drivers/s390/block/dcssblk.c | 1 + fs/block_dev.c | 5 +++-- include/linux/blkdev.h | 2 ++ 5 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/block/brd.c b/drivers/block/brd.c index f5b0d6f..13eee12 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -508,6 +508,9 @@ static struct brd_device *brd_alloc(int i) brd->brd_queue->limits.discard_granularity = PAGE_SIZE; blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); brd->brd_queue->limits.discard_zeroes_data = 1; +#ifdef CONFIG_BLK_DEV_RAM_DAX + queue_flag_set_unlocked(QUEUE_FLAG_DAX, brd->brd_queue); +#endif queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue); disk = brd->brd_disk = alloc_disk(max_part); diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 608fc44..53b701b 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -283,6 +283,7 @@ static int pmem_attach_disk(struct device *dev, blk_queue_max_hw_sectors(q, UINT_MAX); blk_queue_bounce_limit(q, BLK_BOUNCE_ANY); queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q); + queue_flag_set_unlocked(QUEUE_FLAG_DAX, q); q->queuedata = pmem; disk = alloc_disk_node(0, nid); diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c index bed53c4..093e9e1 100644 --- a/drivers/s390/block/dcssblk.c +++ b/drivers/s390/block/dcssblk.c @@ -618,6 +618,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char dev_info->gd->driverfs_dev = &dev_info->dev; blk_queue_make_request(dev_info->dcssblk_queue, dcssblk_make_request); blk_queue_logical_block_size(dev_info->dcssblk_queue, 4096); + queue_flag_set_unlocked(QUEUE_FLAG_DAX, dev_info->dcssblk_queue); seg_byte_size = (dev_info->end - dev_info->start + 1); set_capacity(dev_info->gd, seg_byte_size >> 9); // size in sectors diff --git a/fs/block_dev.c b/fs/block_dev.c index 71ccab1..9bcb3a9 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -484,6 +484,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax) sector_t sector = dax->sector; long avail, size = dax->size; const struct block_device_operations *ops = bdev->bd_disk->fops; + struct request_queue *q = bdev_get_queue(bdev); /* * The device driver is allowed to sleep, in order to make the @@ -493,7 +494,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax) if (size < 0) return size; - if (!ops->direct_access) + if (!blk_queue_dax(q) || !ops->direct_access) return -EOPNOTSUPP; if ((sector + DIV_ROUND_UP(size, 512)) > part_nr_sects_read(bdev->bd_part)) @@ -1287,7 +1288,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part) bdev->bd_disk = disk; bdev->bd_queue = disk->queue; bdev->bd_contains = bdev; - if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && disk->fops->direct_access) + if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && blk_queue_dax(disk->queue)) bdev->bd_inode->i_flags = S_DAX; else bdev->bd_inode->i_flags = 0; diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 9746d22..d5cb326 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -505,6 +505,7 @@ struct request_queue { #define QUEUE_FLAG_WC 23 /* Write back caching */ #define QUEUE_FLAG_FUA 24 /* device supports FUA writes */ #define QUEUE_FLAG_FLUSH_NQ 25 /* flush not queueuable */ +#define QUEUE_FLAG_DAX 26 /* device supports DAX */ #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \ (1 << QUEUE_FLAG_STACKABLE) | \ @@ -594,6 +595,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) #define blk_queue_discard(q) test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags) #define blk_queue_secdiscard(q) (blk_queue_discard(q) && \ test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags)) +#define blk_queue_dax(q) test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags) #define blk_noretry_request(rq) \ ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \ -- 2.7.4 (Apple Git-66)
WARNING: multiple messages have this Message-ID (diff)
From: Mike Snitzer <snitzer@redhat.com> To: "Kani, Toshimitsu" <toshi.kani@hpe.com> Cc: "dan.j.williams@intel.com" <dan.j.williams@intel.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "sandeen@redhat.com" <sandeen@redhat.com>, "linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>, "agk@redhat.com" <agk@redhat.com>, "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>, "viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>, "axboe@kernel.dk" <axboe@kernel.dk>, "axboe@fb.com" <axboe@fb.com>, "ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>, "dm-devel@redhat.com" <dm-devel@redhat.com> Subject: Re: [PATCH 0/6] Support DAX for device-mapper dm-linear devices Date: Wed, 22 Jun 2016 18:38:42 -0400 [thread overview] Message-ID: <20160622223842.GA34512@redhat.com> (raw) In-Reply-To: <1466625958.3504.340.camel@hpe.com> On Wed, Jun 22 2016 at 4:16P -0400, Kani, Toshimitsu <toshi.kani@hpe.com> 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@hpe.com> > > 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@hpe.com> 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@redhat.com> wrote: > > > > > > 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). > > > > > > > > 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: >From e88736ce322f248157da6c7d402e940adafffa1e Mon Sep 17 00:00:00 2001 From: Mike Snitzer <snitzer@redhat.com> Date: Tue, 21 Jun 2016 12:23:29 -0400 Subject: [PATCH] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support Signed-off-by: Mike Snitzer <snitzer@redhat.com> --- drivers/block/brd.c | 3 +++ drivers/nvdimm/pmem.c | 1 + drivers/s390/block/dcssblk.c | 1 + fs/block_dev.c | 5 +++-- include/linux/blkdev.h | 2 ++ 5 files changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/block/brd.c b/drivers/block/brd.c index f5b0d6f..13eee12 100644 --- a/drivers/block/brd.c +++ b/drivers/block/brd.c @@ -508,6 +508,9 @@ static struct brd_device *brd_alloc(int i) brd->brd_queue->limits.discard_granularity = PAGE_SIZE; blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX); brd->brd_queue->limits.discard_zeroes_data = 1; +#ifdef CONFIG_BLK_DEV_RAM_DAX + queue_flag_set_unlocked(QUEUE_FLAG_DAX, brd->brd_queue); +#endif queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue); disk = brd->brd_disk = alloc_disk(max_part); diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c index 608fc44..53b701b 100644 --- a/drivers/nvdimm/pmem.c +++ b/drivers/nvdimm/pmem.c @@ -283,6 +283,7 @@ static int pmem_attach_disk(struct device *dev, blk_queue_max_hw_sectors(q, UINT_MAX); blk_queue_bounce_limit(q, BLK_BOUNCE_ANY); queue_flag_set_unlocked(QUEUE_FLAG_NONROT, q); + queue_flag_set_unlocked(QUEUE_FLAG_DAX, q); q->queuedata = pmem; disk = alloc_disk_node(0, nid); diff --git a/drivers/s390/block/dcssblk.c b/drivers/s390/block/dcssblk.c index bed53c4..093e9e1 100644 --- a/drivers/s390/block/dcssblk.c +++ b/drivers/s390/block/dcssblk.c @@ -618,6 +618,7 @@ dcssblk_add_store(struct device *dev, struct device_attribute *attr, const char dev_info->gd->driverfs_dev = &dev_info->dev; blk_queue_make_request(dev_info->dcssblk_queue, dcssblk_make_request); blk_queue_logical_block_size(dev_info->dcssblk_queue, 4096); + queue_flag_set_unlocked(QUEUE_FLAG_DAX, dev_info->dcssblk_queue); seg_byte_size = (dev_info->end - dev_info->start + 1); set_capacity(dev_info->gd, seg_byte_size >> 9); // size in sectors diff --git a/fs/block_dev.c b/fs/block_dev.c index 71ccab1..9bcb3a9 100644 --- a/fs/block_dev.c +++ b/fs/block_dev.c @@ -484,6 +484,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax) sector_t sector = dax->sector; long avail, size = dax->size; const struct block_device_operations *ops = bdev->bd_disk->fops; + struct request_queue *q = bdev_get_queue(bdev); /* * The device driver is allowed to sleep, in order to make the @@ -493,7 +494,7 @@ long bdev_direct_access(struct block_device *bdev, struct blk_dax_ctl *dax) if (size < 0) return size; - if (!ops->direct_access) + if (!blk_queue_dax(q) || !ops->direct_access) return -EOPNOTSUPP; if ((sector + DIV_ROUND_UP(size, 512)) > part_nr_sects_read(bdev->bd_part)) @@ -1287,7 +1288,7 @@ static int __blkdev_get(struct block_device *bdev, fmode_t mode, int for_part) bdev->bd_disk = disk; bdev->bd_queue = disk->queue; bdev->bd_contains = bdev; - if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && disk->fops->direct_access) + if (IS_ENABLED(CONFIG_BLK_DEV_DAX) && blk_queue_dax(disk->queue)) bdev->bd_inode->i_flags = S_DAX; else bdev->bd_inode->i_flags = 0; diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h index 9746d22..d5cb326 100644 --- a/include/linux/blkdev.h +++ b/include/linux/blkdev.h @@ -505,6 +505,7 @@ struct request_queue { #define QUEUE_FLAG_WC 23 /* Write back caching */ #define QUEUE_FLAG_FUA 24 /* device supports FUA writes */ #define QUEUE_FLAG_FLUSH_NQ 25 /* flush not queueuable */ +#define QUEUE_FLAG_DAX 26 /* device supports DAX */ #define QUEUE_FLAG_DEFAULT ((1 << QUEUE_FLAG_IO_STAT) | \ (1 << QUEUE_FLAG_STACKABLE) | \ @@ -594,6 +595,7 @@ static inline void queue_flag_clear(unsigned int flag, struct request_queue *q) #define blk_queue_discard(q) test_bit(QUEUE_FLAG_DISCARD, &(q)->queue_flags) #define blk_queue_secdiscard(q) (blk_queue_discard(q) && \ test_bit(QUEUE_FLAG_SECDISCARD, &(q)->queue_flags)) +#define blk_queue_dax(q) test_bit(QUEUE_FLAG_DAX, &(q)->queue_flags) #define blk_noretry_request(rq) \ ((rq)->cmd_flags & (REQ_FAILFAST_DEV|REQ_FAILFAST_TRANSPORT| \ -- 2.7.4 (Apple Git-66)
next prev parent reply other threads:[~2016-06-22 22:38 UTC|newest] Thread overview: 91+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-13 22:21 [PATCH 0/6] Support DAX for device-mapper dm-linear devices Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 1/6] genhd: Add GENHD_FL_DAX to gendisk flags Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 2/6] block: Check GENHD_FL_DAX for DAX capability Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 3/6] dm: Add dm_blk_direct_access() for mapped device Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 4/6] dm-linear: Add linear_direct_access() Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 5/6] dm, dm-linear: Add dax_supported to dm_target Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` [PATCH 6/6] dm: Enable DAX support for mapper device Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:21 ` Toshi Kani 2016-06-13 22:57 ` [PATCH 0/6] Support DAX for device-mapper dm-linear devices Mike Snitzer [not found] ` <20160613225756.GA18417-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-20 18:00 ` Mike Snitzer 2016-06-20 18:00 ` Mike Snitzer [not found] ` <20160620180043.GA21261-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-20 18:31 ` Kani, Toshimitsu 2016-06-20 18:31 ` Kani, Toshimitsu [not found] ` <1466446861.3504.243.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-20 19:40 ` Mike Snitzer 2016-06-20 19:40 ` Mike Snitzer [not found] ` <20160620194026.GA21657-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-20 19:52 ` Mike Snitzer 2016-06-20 19:52 ` Mike Snitzer [not found] ` <20160620195217.GB21657-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-20 20:11 ` Kani, Toshimitsu 2016-06-20 20:11 ` Kani, Toshimitsu [not found] ` <1466452883.3504.244.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-20 21:28 ` Kani, Toshimitsu 2016-06-20 21:28 ` Kani, Toshimitsu [not found] ` <1466457467.3504.249.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-20 22:22 ` Mike Snitzer 2016-06-20 22:22 ` Mike Snitzer [not found] ` <20160620222236.GA22461-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-21 13:41 ` Mike Snitzer 2016-06-21 13:41 ` Mike Snitzer [not found] ` <20160621134147.GA26392-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-21 15:44 ` Kani, Toshimitsu 2016-06-21 15:44 ` Kani, Toshimitsu [not found] ` <1466523280.3504.262.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-21 15:50 ` Kani, Toshimitsu 2016-06-21 15:50 ` Kani, Toshimitsu 2016-06-21 16:25 ` Dan Williams 2016-06-21 16:25 ` Dan Williams [not found] ` <CAPcyv4gFREc94ANuFD_Lyddx3iqRTN2UDebgeJe3LqPL8xrVzg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-21 16:35 ` Kani, Toshimitsu 2016-06-21 16:35 ` Kani, Toshimitsu [not found] ` <1466526342.3504.270.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-21 16:45 ` Dan Williams 2016-06-21 16:45 ` Dan Williams [not found] ` <CAPcyv4ht8B7dHe1ckv5d=bOrRzCy3=ZDVSTD0rRsak_LYD8r8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-21 16:56 ` Kani, Toshimitsu 2016-06-21 16:56 ` Kani, Toshimitsu 2016-06-21 18:17 ` Mike Snitzer 2016-06-21 18:17 ` Mike Snitzer 2016-06-22 17:44 ` Kani, Toshimitsu 2016-06-22 17:44 ` Kani, Toshimitsu [not found] ` <1466616868.3504.320.camel-ZPxbGqLxI0U@public.gmane.org> 2016-06-22 19:15 ` Dan Williams 2016-06-22 19:15 ` Dan Williams 2016-06-22 20:16 ` Kani, Toshimitsu 2016-06-22 22:38 ` Mike Snitzer [this message] 2016-06-22 22:38 ` Mike Snitzer [not found] ` <20160622223842.GA34512-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> 2016-06-22 22:59 ` Kani, Toshimitsu 2016-06-22 22:59 ` Kani, Toshimitsu 2016-06-13 23:18 ` Dan Williams 2016-06-13 23:18 ` Dan Williams 2016-06-13 23:18 ` Dan Williams 2016-06-13 23:59 ` Kani, Toshimitsu 2016-06-13 23:59 ` Kani, Toshimitsu 2016-06-13 23:59 ` Kani, Toshimitsu 2016-06-14 0:02 ` Dan Williams 2016-06-14 0:02 ` Dan Williams 2016-06-14 0:02 ` Dan Williams 2016-06-14 7:30 ` Dan Williams 2016-06-14 7:30 ` Dan Williams 2016-06-14 7:30 ` Dan Williams 2016-06-14 13:50 ` Jeff Moyer 2016-06-14 13:50 ` Jeff Moyer 2016-06-14 13:50 ` Jeff Moyer 2016-06-14 15:41 ` Mike Snitzer 2016-06-14 15:41 ` Mike Snitzer 2016-06-14 15:41 ` Mike Snitzer 2016-06-14 18:00 ` Kani, Toshimitsu 2016-06-14 20:19 ` Jeff Moyer 2016-06-14 20:19 ` Jeff Moyer 2016-06-14 20:19 ` Jeff Moyer 2016-06-15 1:46 ` Mike Snitzer 2016-06-15 1:46 ` Mike Snitzer 2016-06-15 2:07 ` Dan Williams 2016-06-15 2:07 ` Dan Williams 2016-06-15 2:35 ` Mike Snitzer 2016-06-15 2:35 ` Mike Snitzer 2016-06-14 15:53 ` Kani, Toshimitsu
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20160622223842.GA34512@redhat.com \ --to=snitzer@redhat.com \ --cc=agk@redhat.com \ --cc=axboe@fb.com \ --cc=axboe@kernel.dk \ --cc=dan.j.williams@intel.com \ --cc=dm-devel@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-nvdimm@ml01.01.org \ --cc=linux-raid@vger.kernel.org \ --cc=ross.zwisler@linux.intel.com \ --cc=sandeen@redhat.com \ --cc=toshi.kani@hpe.com \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.