* [PATCH v3 1/4] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support
2016-06-23 21:05 [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
@ 2016-06-23 21:05 ` Mike Snitzer
2016-06-23 21:05 ` [PATCH v3 2/4] block: expose QUEUE_FLAG_DAX in sysfs Mike Snitzer
` (3 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2016-06-23 21:05 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: ross.zwisler, viro, linux-nvdimm, dm-devel, linux-kernel, yigal
From: Toshi Kani <toshi.kani@hpe.com>
Currently, presence of direct_access() in block_device_operations
indicates support of DAX on its block device. Because
block_device_operations is instantiated with 'const', this DAX
capablity may not be enabled conditinally.
In preparation for supporting DAX to device-mapper devices, add
QUEUE_FLAG_DAX to request_queue flags to advertise their DAX
support. This will allow to set the DAX capability based on how
mapped device is composed.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: <linux-s390@vger.kernel.org>
---
drivers/block/brd.c | 4 +++-
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(+), 3 deletions(-)
diff --git a/drivers/block/brd.c b/drivers/block/brd.c
index f5b0d6f..dd96a93 100644
--- a/drivers/block/brd.c
+++ b/drivers/block/brd.c
@@ -509,7 +509,9 @@ static struct brd_device *brd_alloc(int i)
blk_queue_max_discard_sectors(brd->brd_queue, UINT_MAX);
brd->brd_queue->limits.discard_zeroes_data = 1;
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, brd->brd_queue);
-
+#ifdef CONFIG_BLK_DEV_RAM_DAX
+ queue_flag_set_unlocked(QUEUE_FLAG_DAX, brd->brd_queue);
+#endif
disk = brd->brd_disk = alloc_disk(max_part);
if (!disk)
goto out_free_queue;
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..d012be4 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -493,7 +493,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(bdev_get_queue(bdev)) || !ops->direct_access)
return -EOPNOTSUPP;
if ((sector + DIV_ROUND_UP(size, 512)) >
part_nr_sects_read(bdev->bd_part))
@@ -1287,7 +1287,8 @@ 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..1493ab3 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)
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v3 2/4] block: expose QUEUE_FLAG_DAX in sysfs
2016-06-23 21:05 [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
2016-06-23 21:05 ` [PATCH v3 1/4] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support Mike Snitzer
@ 2016-06-23 21:05 ` Mike Snitzer
2016-06-23 21:05 ` [PATCH v3 3/4] dm: add infrastructure for DAX support Mike Snitzer
` (2 subsequent siblings)
4 siblings, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2016-06-23 21:05 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: ross.zwisler, viro, linux-nvdimm, dm-devel, linux-kernel, yigal
From: Yigal Korman <yigal@plexistor.com>
Provides the ability to identify DAX enabled devices in userspace.
Signed-off-by: Yigal Korman <yigal@plexistor.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
---
block/blk-sysfs.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c
index 9920596..f87a7e7 100644
--- a/block/blk-sysfs.c
+++ b/block/blk-sysfs.c
@@ -379,6 +379,11 @@ static ssize_t queue_wc_store(struct request_queue *q, const char *page,
return count;
}
+static ssize_t queue_dax_show(struct request_queue *q, char *page)
+{
+ return queue_var_show(blk_queue_dax(q), page);
+}
+
static struct queue_sysfs_entry queue_requests_entry = {
.attr = {.name = "nr_requests", .mode = S_IRUGO | S_IWUSR },
.show = queue_requests_show,
@@ -516,6 +521,11 @@ static struct queue_sysfs_entry queue_wc_entry = {
.store = queue_wc_store,
};
+static struct queue_sysfs_entry queue_dax_entry = {
+ .attr = {.name = "dax", .mode = S_IRUGO },
+ .show = queue_dax_show,
+};
+
static struct attribute *default_attrs[] = {
&queue_requests_entry.attr,
&queue_ra_entry.attr,
@@ -542,6 +552,7 @@ static struct attribute *default_attrs[] = {
&queue_random_entry.attr,
&queue_poll_entry.attr,
&queue_wc_entry.attr,
+ &queue_dax_entry.attr,
NULL,
};
--
2.7.4 (Apple Git-66)
^ permalink raw reply related [flat|nested] 12+ messages in thread* [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-23 21:05 [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
2016-06-23 21:05 ` [PATCH v3 1/4] block: add QUEUE_FLAG_DAX for devices to advertise their DAX support Mike Snitzer
2016-06-23 21:05 ` [PATCH v3 2/4] block: expose QUEUE_FLAG_DAX in sysfs Mike Snitzer
@ 2016-06-23 21:05 ` Mike Snitzer
2016-06-23 23:36 ` Kani, Toshimitsu
2016-06-23 21:05 ` [PATCH v3 4/4] dm linear: add " Mike Snitzer
2016-06-30 17:00 ` [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
4 siblings, 1 reply; 12+ messages in thread
From: Mike Snitzer @ 2016-06-23 21:05 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: ross.zwisler, viro, linux-nvdimm, dm-devel, linux-kernel, yigal
From: Toshi Kani <toshi.kani@hpe.com>
Change mapped device to implement direct_access function,
dm_blk_direct_access(), which calls a target direct_access function.
'struct target_type' is extended to have target direct_access interface.
This function limits direct accessible size to the dm_target's limit
with max_io_len().
Add dm_table_supports_dax() to iterate all targets and associated block
devices to check for DAX support. To add DAX support to a DM target the
target must only implement the direct_access function.
Add a new dm type, DM_TYPE_DAX_BIO_BASED, which indicates that mapped
device supports DAX and is bio based. This new type is used to assure
that all target devices have DAX support and remain that way after
QUEUE_FLAG_DAX is set in mapped device.
At initial table load, QUEUE_FLAG_DAX is set to mapped device when setting
DM_TYPE_DAX_BIO_BASED to the type. Any subsequent table load to the
mapped device must have the same type, or else it fails per the check in
table_load().
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
---
drivers/md/dm-table.c | 44 ++++++++++++++++++++++++++++++++++++++++++-
drivers/md/dm.c | 38 +++++++++++++++++++++++++++++++++++--
drivers/md/dm.h | 1 +
include/linux/device-mapper.h | 10 ++++++++++
include/uapi/linux/dm-ioctl.h | 4 ++--
5 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 88f0174..ee6f37e 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -827,6 +827,12 @@ void dm_consume_args(struct dm_arg_set *as, unsigned num_args)
}
EXPORT_SYMBOL(dm_consume_args);
+static bool __table_type_bio_based(unsigned table_type)
+{
+ return (table_type == DM_TYPE_BIO_BASED ||
+ table_type == DM_TYPE_DAX_BIO_BASED);
+}
+
static bool __table_type_request_based(unsigned table_type)
{
return (table_type == DM_TYPE_REQUEST_BASED ||
@@ -839,6 +845,34 @@ void dm_table_set_type(struct dm_table *t, unsigned type)
}
EXPORT_SYMBOL_GPL(dm_table_set_type);
+static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
+ sector_t start, sector_t len, void *data)
+{
+ struct request_queue *q = bdev_get_queue(dev->bdev);
+
+ return q && blk_queue_dax(q);
+}
+
+static bool dm_table_supports_dax(struct dm_table *t)
+{
+ struct dm_target *ti;
+ unsigned i = 0;
+
+ /* Ensure that all targets support DAX. */
+ while (i < dm_table_get_num_targets(t)) {
+ ti = dm_table_get_target(t, i++);
+
+ if (!ti->type->direct_access)
+ return false;
+
+ if (!ti->type->iterate_devices ||
+ !ti->type->iterate_devices(ti, device_supports_dax, NULL))
+ return false;
+ }
+
+ return true;
+}
+
static int dm_table_determine_type(struct dm_table *t)
{
unsigned i;
@@ -853,6 +887,7 @@ static int dm_table_determine_type(struct dm_table *t)
/* target already set the table's type */
if (t->type == DM_TYPE_BIO_BASED)
return 0;
+ BUG_ON(t->type == DM_TYPE_DAX_BIO_BASED);
goto verify_rq_based;
}
@@ -887,6 +922,8 @@ static int dm_table_determine_type(struct dm_table *t)
if (bio_based) {
/* We must use this table as bio-based */
t->type = DM_TYPE_BIO_BASED;
+ if (dm_table_supports_dax(t))
+ t->type = DM_TYPE_DAX_BIO_BASED;
return 0;
}
@@ -979,6 +1016,11 @@ struct dm_target *dm_table_get_wildcard_target(struct dm_table *t)
return NULL;
}
+bool dm_table_bio_based(struct dm_table *t)
+{
+ return __table_type_bio_based(dm_table_get_type(t));
+}
+
bool dm_table_request_based(struct dm_table *t)
{
return __table_type_request_based(dm_table_get_type(t));
@@ -1001,7 +1043,7 @@ static int dm_table_alloc_md_mempools(struct dm_table *t, struct mapped_device *
return -EINVAL;
}
- if (type == DM_TYPE_BIO_BASED)
+ if (__table_type_bio_based(type))
for (i = 0; i < t->num_targets; i++) {
tgt = t->targets + i;
per_io_data_size = max(per_io_data_size, tgt->per_io_data_size);
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 2c907bc..62f6c24 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -905,6 +905,33 @@ int dm_set_target_max_io_len(struct dm_target *ti, sector_t len)
}
EXPORT_SYMBOL_GPL(dm_set_target_max_io_len);
+static long dm_blk_direct_access(struct block_device *bdev, sector_t sector,
+ void __pmem **kaddr, pfn_t *pfn, long size)
+{
+ struct mapped_device *md = bdev->bd_disk->private_data;
+ struct dm_table *map;
+ struct dm_target *ti;
+ int srcu_idx;
+ long len, ret = -EIO;
+
+ map = dm_get_live_table(md, &srcu_idx);
+ if (!map)
+ goto out;
+
+ ti = dm_table_find_target(map, sector);
+ if (!dm_target_is_valid(ti))
+ goto out;
+
+ len = max_io_len(sector, ti) << SECTOR_SHIFT;
+ size = min(len, size);
+
+ if (ti->type->direct_access)
+ ret = ti->type->direct_access(ti, sector, kaddr, pfn, size);
+out:
+ dm_put_live_table(md, srcu_idx);
+ return min(ret, size);
+}
+
/*
* A target may call dm_accept_partial_bio only from the map routine. It is
* allowed for all bio types except REQ_PREFLUSH.
@@ -1548,7 +1575,7 @@ static void __bind_mempools(struct mapped_device *md, struct dm_table *t)
if (md->bs) {
/* The md already has necessary mempools. */
- if (dm_table_get_type(t) == DM_TYPE_BIO_BASED) {
+ if (dm_table_bio_based(t)) {
/*
* Reload bioset because front_pad may have changed
* because a different table was loaded.
@@ -1744,8 +1771,9 @@ EXPORT_SYMBOL_GPL(dm_get_queue_limits);
int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
{
int r;
+ unsigned type = dm_get_md_type(md);
- switch (dm_get_md_type(md)) {
+ switch (type) {
case DM_TYPE_REQUEST_BASED:
r = dm_old_init_request_queue(md);
if (r) {
@@ -1761,6 +1789,7 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
}
break;
case DM_TYPE_BIO_BASED:
+ case DM_TYPE_DAX_BIO_BASED:
dm_init_normal_md_queue(md);
blk_queue_make_request(md->queue, dm_make_request);
/*
@@ -1769,6 +1798,9 @@ int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t)
*/
bioset_free(md->queue->bio_split);
md->queue->bio_split = NULL;
+
+ if (type == DM_TYPE_DAX_BIO_BASED)
+ queue_flag_set_unlocked(QUEUE_FLAG_DAX, md->queue);
break;
}
@@ -2465,6 +2497,7 @@ struct dm_md_mempools *dm_alloc_md_mempools(struct mapped_device *md, unsigned t
switch (type) {
case DM_TYPE_BIO_BASED:
+ case DM_TYPE_DAX_BIO_BASED:
cachep = _io_cache;
pool_size = dm_get_reserved_bio_based_ios();
front_pad = roundup(per_io_data_size, __alignof__(struct dm_target_io)) + offsetof(struct dm_target_io, clone);
@@ -2641,6 +2674,7 @@ static const struct block_device_operations dm_blk_dops = {
.open = dm_blk_open,
.release = dm_blk_close,
.ioctl = dm_blk_ioctl,
+ .direct_access = dm_blk_direct_access,
.getgeo = dm_blk_getgeo,
.pr_ops = &dm_pr_ops,
.owner = THIS_MODULE
diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index 2e0e4a5..f0aad08 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -68,6 +68,7 @@ unsigned dm_table_get_type(struct dm_table *t);
struct target_type *dm_table_get_immutable_target_type(struct dm_table *t);
struct dm_target *dm_table_get_immutable_target(struct dm_table *t);
struct dm_target *dm_table_get_wildcard_target(struct dm_table *t);
+bool dm_table_bio_based(struct dm_table *t);
bool dm_table_request_based(struct dm_table *t);
bool dm_table_all_blk_mq_devices(struct dm_table *t);
void dm_table_free_md_mempools(struct dm_table *t);
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 2ce3392..b0db857 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -26,6 +26,7 @@ struct bio_vec;
#define DM_TYPE_BIO_BASED 1
#define DM_TYPE_REQUEST_BASED 2
#define DM_TYPE_MQ_REQUEST_BASED 3
+#define DM_TYPE_DAX_BIO_BASED 4
typedef enum { STATUSTYPE_INFO, STATUSTYPE_TABLE } status_type_t;
@@ -124,6 +125,14 @@ typedef void (*dm_io_hints_fn) (struct dm_target *ti,
*/
typedef int (*dm_busy_fn) (struct dm_target *ti);
+/*
+ * Returns:
+ * < 0 : error
+ * >= 0 : the number of bytes accessible at the address
+ */
+typedef long (*dm_direct_access_fn) (struct dm_target *ti, sector_t sector,
+ void __pmem **kaddr, pfn_t *pfn, long size);
+
void dm_error(const char *message);
struct dm_dev {
@@ -170,6 +179,7 @@ struct target_type {
dm_busy_fn busy;
dm_iterate_devices_fn iterate_devices;
dm_io_hints_fn io_hints;
+ dm_direct_access_fn direct_access;
/* For internal device-mapper use. */
struct list_head list;
diff --git a/include/uapi/linux/dm-ioctl.h b/include/uapi/linux/dm-ioctl.h
index 30afd0a..4bf9f1e 100644
--- a/include/uapi/linux/dm-ioctl.h
+++ b/include/uapi/linux/dm-ioctl.h
@@ -267,9 +267,9 @@ enum {
#define DM_DEV_SET_GEOMETRY _IOWR(DM_IOCTL, DM_DEV_SET_GEOMETRY_CMD, struct dm_ioctl)
#define DM_VERSION_MAJOR 4
-#define DM_VERSION_MINOR 34
+#define DM_VERSION_MINOR 35
#define DM_VERSION_PATCHLEVEL 0
-#define DM_VERSION_EXTRA "-ioctl (2015-10-28)"
+#define DM_VERSION_EXTRA "-ioctl (2016-06-23)"
/* Status bits */
#define DM_READONLY_FLAG (1 << 0) /* In/Out */
--
2.7.4 (Apple Git-66)
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-23 21:05 ` [PATCH v3 3/4] dm: add infrastructure for DAX support Mike Snitzer
@ 2016-06-23 23:36 ` Kani, Toshimitsu
2016-06-24 1:49 ` Mike Snitzer
0 siblings, 1 reply; 12+ messages in thread
From: Kani, Toshimitsu @ 2016-06-23 23:36 UTC (permalink / raw)
To: dan.j.williams, snitzer, axboe
Cc: dm-devel, ross.zwisler, viro, linux-kernel, linux-nvdimm, yigal
On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
:
> +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> + sector_t start, sector_t len, void *data)
> +{
> + struct request_queue *q = bdev_get_queue(dev->bdev);
> +
> + return q && blk_queue_dax(q);
> +}
> +
> +static bool dm_table_supports_dax(struct dm_table *t)
> +{
> + struct dm_target *ti;
> + unsigned i = 0;
> +
> + /* Ensure that all targets support DAX. */
> + while (i < dm_table_get_num_targets(t)) {
> + ti = dm_table_get_target(t, i++);
> +
> + if (!ti->type->direct_access)
> + return false;
> +
> + if (!ti->type->iterate_devices ||
> + !ti->type->iterate_devices(ti, device_supports_dax,
> NULL))
> + return false;
> + }
> +
> + return true;
> +}
> +
Hi Mike,
Thanks for the update. I have a question about the above change. Targets may
have their own parameters. For instance, dm-stripe has 'chunk_size', which is
checked in stripe_ctr(). DAX adds additional restriction that chunk_size
needs to be aligned by page size. So, I think we need to keep target
responsible to verify if DAX can be supported. What do you think?
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-23 23:36 ` Kani, Toshimitsu
@ 2016-06-24 1:49 ` Mike Snitzer
2016-06-24 15:40 ` Kani, Toshimitsu
0 siblings, 1 reply; 12+ messages in thread
From: Mike Snitzer @ 2016-06-24 1:49 UTC (permalink / raw)
To: Kani, Toshimitsu
Cc: dan.j.williams, axboe, dm-devel, ross.zwisler, viro,
linux-kernel, linux-nvdimm, yigal
On Thu, Jun 23 2016 at 7:36pm -0400,
Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
> :
> > +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> > + sector_t start, sector_t len, void *data)
> > +{
> > + struct request_queue *q = bdev_get_queue(dev->bdev);
> > +
> > + return q && blk_queue_dax(q);
> > +}
> > +
> > +static bool dm_table_supports_dax(struct dm_table *t)
> > +{
> > + struct dm_target *ti;
> > + unsigned i = 0;
> > +
> > + /* Ensure that all targets support DAX. */
> > + while (i < dm_table_get_num_targets(t)) {
> > + ti = dm_table_get_target(t, i++);
> > +
> > + if (!ti->type->direct_access)
> > + return false;
> > +
> > + if (!ti->type->iterate_devices ||
> > + !ti->type->iterate_devices(ti, device_supports_dax,
> > NULL))
> > + return false;
> > + }
> > +
> > + return true;
> > +}
> > +
>
> Hi Mike,
>
> Thanks for the update. I have a question about the above change. Targets may
> have their own parameters. For instance, dm-stripe has 'chunk_size', which is
> checked in stripe_ctr(). DAX adds additional restriction that chunk_size
> needs to be aligned by page size. So, I think we need to keep target
> responsible to verify if DAX can be supported. What do you think?
We've never had to concern the dm-stripe target with hardware
specific chunk_size validation. The user is able to specify the
chunk_size via lvm2's lvcreate -I argument. Yes this gives users enough
rope to hang themselves but it is very easy to configure a dm-stripe
device with the appropriate chunk size (PAGE_SIZE) from userspace.
But lvm2 could even be trained to make sure the chunk_size is a factor
of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
devices export queue/dax=1
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-24 1:49 ` Mike Snitzer
@ 2016-06-24 15:40 ` Kani, Toshimitsu
2016-06-24 15:44 ` Mike Snitzer
0 siblings, 1 reply; 12+ messages in thread
From: Kani, Toshimitsu @ 2016-06-24 15:40 UTC (permalink / raw)
To: snitzer
Cc: linux-kernel, linux-nvdimm, viro, dan.j.williams, axboe,
ross.zwisler, dm-devel, yigal
On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> On Thu, Jun 23 2016 at 7:36pm -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
:
> > Thanks for the update. I have a question about the above change. Targets
> > may have their own parameters. For instance, dm-stripe has 'chunk_size',
> > which is checked in stripe_ctr(). DAX adds additional restriction that
> > chunk_size needs to be aligned by page size. So, I think we need to keep
> > target responsible to verify if DAX can be supported. What do you think?
>
> We've never had to concern the dm-stripe target with hardware
> specific chunk_size validation. The user is able to specify the
> chunk_size via lvm2's lvcreate -I argument. Yes this gives users enough
> rope to hang themselves but it is very easy to configure a dm-stripe
> device with the appropriate chunk size (PAGE_SIZE) from userspace.
>
> But lvm2 could even be trained to make sure the chunk_size is a factor
> of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> devices export queue/dax=1
lvcreate -I only allows multiple of page size, so we are OK with lvm2. I was
wondering if the check in lvm2 is enough. Are there any other tools that may
be used to configure stripe size? Can we trust userspace on this?
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-24 15:40 ` Kani, Toshimitsu
@ 2016-06-24 15:44 ` Mike Snitzer
2016-06-24 15:56 ` Kani, Toshimitsu
0 siblings, 1 reply; 12+ messages in thread
From: Mike Snitzer @ 2016-06-24 15:44 UTC (permalink / raw)
To: Kani, Toshimitsu
Cc: axboe, linux-nvdimm, linux-kernel, dm-devel, viro, yigal,
dan.j.williams, ross.zwisler
On Fri, Jun 24 2016 at 11:40am -0400,
Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > On Thu, Jun 23 2016 at 7:36pm -0400,
> > Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> :
> > > Thanks for the update. I have a question about the above change. Targets
> > > may have their own parameters. For instance, dm-stripe has 'chunk_size',
> > > which is checked in stripe_ctr(). DAX adds additional restriction that
> > > chunk_size needs to be aligned by page size. So, I think we need to keep
> > > target responsible to verify if DAX can be supported. What do you think?
> >
> > We've never had to concern the dm-stripe target with hardware
> > specific chunk_size validation. The user is able to specify the
> > chunk_size via lvm2's lvcreate -I argument. Yes this gives users enough
> > rope to hang themselves but it is very easy to configure a dm-stripe
> > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> >
> > But lvm2 could even be trained to make sure the chunk_size is a factor
> > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > devices export queue/dax=1
>
> lvcreate -I only allows multiple of page size, so we are OK with lvm2. I was
> wondering if the check in lvm2 is enough. Are there any other tools that may
> be used to configure stripe size? Can we trust userspace on this?
Other than lvm2, I'm not aware of any other userspace tool that is
driving the dm-stripe target configuration. So I think we can trust
userspace here until proven otherwise. Good news is that any
misconfiguration will simply not work right? Errors would result from
improperly sized IO right?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
2016-06-24 15:44 ` Mike Snitzer
@ 2016-06-24 15:56 ` Kani, Toshimitsu
0 siblings, 0 replies; 12+ messages in thread
From: Kani, Toshimitsu @ 2016-06-24 15:56 UTC (permalink / raw)
To: snitzer
Cc: linux-kernel, linux-nvdimm, viro, dan.j.williams, axboe,
ross.zwisler, dm-devel, yigal
On Fri, 2016-06-24 at 11:44 -0400, Mike Snitzer wrote:
> On Fri, Jun 24 2016 at 11:40am -0400,
> Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > >
> > > On Thu, Jun 23 2016 at 7:36pm -0400,
> > > Kani, Toshimitsu <toshi.kani@hpe.com> wrote:
> > > > Thanks for the update. I have a question about the above change.
> > > > Targets may have their own parameters. For instance, dm-stripe has
> > > > 'chunk_size', which is checked in stripe_ctr(). DAX adds additional
> > > > restriction that chunk_size needs to be aligned by page size. So, I
> > > > think we need to keep target responsible to verify if DAX can be
> > > > supported. What do you think?
> > >
> > > We've never had to concern the dm-stripe target with hardware
> > > specific chunk_size validation. The user is able to specify the
> > > chunk_size via lvm2's lvcreate -I argument. Yes this gives users enough
> > > rope to hang themselves but it is very easy to configure a dm-stripe
> > > device with the appropriate chunk size (PAGE_SIZE) from userspace.
> > >
> > > But lvm2 could even be trained to make sure the chunk_size is a factor
> > > of physical_block_size (PAGE_SIZE in the case of pmem) if the underlying
> > > devices export queue/dax=1
> >
> > lvcreate -I only allows multiple of page size, so we are OK with lvm2. I
> > was wondering if the check in lvm2 is enough. Are there any other tools
> > that may be used to configure stripe size? Can we trust userspace on
> > this?
>
> Other than lvm2, I'm not aware of any other userspace tool that is
> driving the dm-stripe target configuration. So I think we can trust
> userspace here until proven otherwise.
Good.
> Good news is that any
> misconfiguration will simply not work right? Errors would result from
> improperly sized IO right?
dax provides direct access with respect to data. So, yes, IO to data fails,
but IO to metadata still succeeds. This may result in creating empty files,
etc.
Thanks,
-Toshi
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 4/4] dm linear: add DAX support
2016-06-23 21:05 [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
` (2 preceding siblings ...)
2016-06-23 21:05 ` [PATCH v3 3/4] dm: add infrastructure for DAX support Mike Snitzer
@ 2016-06-23 21:05 ` Mike Snitzer
2016-06-30 17:00 ` [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
4 siblings, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2016-06-23 21:05 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: ross.zwisler, viro, linux-nvdimm, dm-devel, linux-kernel, yigal
From: Toshi Kani <toshi.kani@hpe.com>
Change dm-linear to implement direct_access function,
linear_direct_access(), which maps sector and calls direct_access
function of its physical target device.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: Alasdair Kergon <agk@redhat.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
---
drivers/md/dm-linear.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-linear.c b/drivers/md/dm-linear.c
index 05c35aa..6d35dd4 100644
--- a/drivers/md/dm-linear.c
+++ b/drivers/md/dm-linear.c
@@ -141,9 +141,27 @@ static int linear_iterate_devices(struct dm_target *ti,
return fn(ti, lc->dev, lc->start, ti->len, data);
}
+static long linear_direct_access(struct dm_target *ti, sector_t sector,
+ void __pmem **kaddr, pfn_t *pfn, long size)
+{
+ struct linear_c *lc = ti->private;
+ struct block_device *bdev = lc->dev->bdev;
+ struct blk_dax_ctl dax = {
+ .sector = linear_map_sector(ti, sector),
+ .size = size,
+ };
+ long ret;
+
+ ret = bdev_direct_access(bdev, &dax);
+ *kaddr = dax.addr;
+ *pfn = dax.pfn;
+
+ return ret;
+}
+
static struct target_type linear_target = {
.name = "linear",
- .version = {1, 2, 1},
+ .version = {1, 3, 0},
.module = THIS_MODULE,
.ctr = linear_ctr,
.dtr = linear_dtr,
@@ -151,6 +169,7 @@ static struct target_type linear_target = {
.status = linear_status,
.prepare_ioctl = linear_prepare_ioctl,
.iterate_devices = linear_iterate_devices,
+ .direct_access = linear_direct_access,
};
int __init dm_linear_init(void)
--
2.7.4 (Apple Git-66)
^ permalink raw reply related [flat|nested] 12+ messages in thread* Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices
2016-06-23 21:05 [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
` (3 preceding siblings ...)
2016-06-23 21:05 ` [PATCH v3 4/4] dm linear: add " Mike Snitzer
@ 2016-06-30 17:00 ` Mike Snitzer
2016-07-08 19:30 ` Mike Snitzer
4 siblings, 1 reply; 12+ messages in thread
From: Mike Snitzer @ 2016-06-30 17:00 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: linux-nvdimm, dm-devel, linux-kernel, yigal, viro, ross.zwisler
On Thu, Jun 23 2016 at 5:05pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> Jens, please pick up the first 2 block patches and I'll get the other
> 2 DM patches staged for 4.8.
Hey Jens,
Looks like you're back so I figured I'd ping you on these first 2 block
patches again. Can you pick them up for 4.8/core?
Thanks,
Mike
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [PATCH v3 0/4] Support DAX for device-mapper linear devices
2016-06-30 17:00 ` [PATCH v3 0/4] Support DAX for device-mapper linear devices Mike Snitzer
@ 2016-07-08 19:30 ` Mike Snitzer
0 siblings, 0 replies; 12+ messages in thread
From: Mike Snitzer @ 2016-07-08 19:30 UTC (permalink / raw)
To: axboe, toshi.kani, dan.j.williams
Cc: linux-nvdimm, dm-devel, linux-kernel, yigal, viro, ross.zwisler
On Thu, Jun 30 2016 at 1:00pm -0400,
Mike Snitzer <snitzer@redhat.com> wrote:
> On Thu, Jun 23 2016 at 5:05pm -0400,
> Mike Snitzer <snitzer@redhat.com> wrote:
>
> > Jens, please pick up the first 2 block patches and I'll get the other
> > 2 DM patches staged for 4.8.
>
> Hey Jens,
>
> Looks like you're back so I figured I'd ping you on these first 2 block
> patches again. Can you pick them up for 4.8/core?
>
> Thanks,
> Mike
ping^2
^ permalink raw reply [flat|nested] 12+ messages in thread