All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kani, Toshimitsu" <toshi.kani-ZPxbGqLxI0U@public.gmane.org>
To: "snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
	<snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org"
	<axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org>,
	"linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org"
	<linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org"
	<dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org"
	<viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
Date: Fri, 24 Jun 2016 15:56:17 +0000	[thread overview]
Message-ID: <1466783775.3504.398.camel@hpe.com> (raw)
In-Reply-To: <20160624154446.GB13898-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

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
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: "Kani, Toshimitsu" <toshi.kani@hpe.com>
To: "snitzer@redhat.com" <snitzer@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-nvdimm@ml01.01.org" <linux-nvdimm@ml01.01.org>,
	"viro@zeniv.linux.org.uk" <viro@zeniv.linux.org.uk>,
	"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
	"axboe@kernel.dk" <axboe@kernel.dk>,
	"ross.zwisler@linux.intel.com" <ross.zwisler@linux.intel.com>,
	"dm-devel@redhat.com" <dm-devel@redhat.com>,
	"yigal@plexistor.com" <yigal@plexistor.com>
Subject: Re: [PATCH v3 3/4] dm: add infrastructure for DAX support
Date: Fri, 24 Jun 2016 15:56:17 +0000	[thread overview]
Message-ID: <1466783775.3504.398.camel@hpe.com> (raw)
In-Reply-To: <20160624154446.GB13898@redhat.com>

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

  parent reply	other threads:[~2016-06-24 15:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
     [not found] ` <1466715953-40692-1-git-send-email-snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
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 2/4] block: expose QUEUE_FLAG_DAX in sysfs 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
2016-06-23 21:05     ` Mike Snitzer
     [not found]     ` <1466715953-40692-4-git-send-email-snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-06-23 23:36       ` Kani, Toshimitsu
2016-06-23 23:36         ` Kani, Toshimitsu
     [not found]         ` <1466724984.3504.380.camel-ZPxbGqLxI0U@public.gmane.org>
2016-06-24  1:49           ` Mike Snitzer
2016-06-24  1:49             ` Mike Snitzer
     [not found]             ` <20160624014930.GA10540-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-06-24 15:40               ` Kani, Toshimitsu
2016-06-24 15:40                 ` Kani, Toshimitsu
     [not found]                 ` <1466782822.3504.391.camel-ZPxbGqLxI0U@public.gmane.org>
2016-06-24 15:44                   ` Mike Snitzer
2016-06-24 15:44                     ` Mike Snitzer
     [not found]                     ` <20160624154446.GB13898-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-06-24 15:56                       ` Kani, Toshimitsu [this message]
2016-06-24 15:56                         ` Kani, Toshimitsu
2016-06-23 21:05   ` [PATCH v3 4/4] dm linear: add " 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
2016-06-30 17:00     ` Mike Snitzer
     [not found]     ` <20160630170053.GA20750-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-07-08 19:30       ` Mike Snitzer
2016-07-08 19:30         ` Mike Snitzer

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=1466783775.3504.398.camel@hpe.com \
    --to=toshi.kani-zpxbgqlxi0u@public.gmane.org \
    --cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
    --cc=dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nvdimm-y27Ovi1pjclAfugRpC6u6w@public.gmane.org \
    --cc=snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    /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: link
Be 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.