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