On Fri, Jun 24 2016 at 11:40am -0400,
Kani, Toshimitsu <toshi.kani(a)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(a)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
> > 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?