Re: [PATCH] dm stripe: add DAX support

2016-06-24 Thread kbuild test robot 
Hi,

[auto build test ERROR on dm/for-next]
[also build test ERROR on v4.7-rc4 next-20160624]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toshi-Kani/dm-stripe-add-DAX-support/20160625-022600
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git 
for-next
config: x86_64-randconfig-s5-06250328 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-1) 6.1.1 20160430
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

>> drivers/md/dm-stripe.c:452:2: error: unknown field 'direct_access' specified 
>> in initializer
 .direct_access = stripe_direct_access,
 ^
>> drivers/md/dm-stripe.c:452:19: error: initialization from incompatible 
>> pointer type [-Werror=incompatible-pointer-types]
 .direct_access = stripe_direct_access,
  ^~~~
   drivers/md/dm-stripe.c:452:19: note: (near initialization for 
'stripe_target.list.next')
>> drivers/md/dm-stripe.c:441:43: warning: missing braces around initializer 
>> [-Wmissing-braces]
static struct target_type stripe_target = {
  ^
   drivers/md/dm-stripe.c:441:43: note: (near initialization for 
'stripe_target')
   cc1: some warnings being treated as errors

vim +/direct_access +452 drivers/md/dm-stripe.c

   435  unsigned chunk_size = sc->chunk_size << SECTOR_SHIFT;
   436  
   437  blk_limits_io_min(limits, chunk_size);
   438  blk_limits_io_opt(limits, chunk_size * sc->stripes);
   439  }
   440  
 > 441  static struct target_type stripe_target = {
   442  .name   = "striped",
   443  .version = {1, 5, 1},
   444  .module = THIS_MODULE,
   445  .ctr= stripe_ctr,
   446  .dtr= stripe_dtr,
   447  .map= stripe_map,
   448  .end_io = stripe_end_io,
   449  .status = stripe_status,
   450  .iterate_devices = stripe_iterate_devices,
   451  .io_hints = stripe_io_hints,
 > 452  .direct_access = stripe_direct_access,
   453  };
   454  
   455  int __init dm_stripe_init(void)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] dm stripe: add DAX support

2016-06-24 Thread kbuild test robot 
Hi,

[auto build test WARNING on dm/for-next]
[also build test WARNING on v4.7-rc4 next-20160624]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Toshi-Kani/dm-stripe-add-DAX-support/20160625-022600
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git 
for-next
config: m68k-sun3_defconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m68k 

All warnings (new ones prefixed by >>):

   drivers/md/dm-stripe.c:452:2: error: unknown field 'direct_access' specified 
in initializer
 .direct_access = stripe_direct_access,
 ^
   drivers/md/dm-stripe.c:452:2: warning: missing braces around initializer 
[-Wmissing-braces]
   drivers/md/dm-stripe.c:452:2: warning: (near initialization for 
'stripe_target.list') [-Wmissing-braces]
>> drivers/md/dm-stripe.c:452:2: warning: initialization from incompatible 
>> pointer type
   drivers/md/dm-stripe.c:452:2: warning: (near initialization for 
'stripe_target.list.next')

vim +452 drivers/md/dm-stripe.c

   436  
   437  blk_limits_io_min(limits, chunk_size);
   438  blk_limits_io_opt(limits, chunk_size * sc->stripes);
   439  }
   440  
   441  static struct target_type stripe_target = {
   442  .name   = "striped",
   443  .version = {1, 5, 1},
   444  .module = THIS_MODULE,
   445  .ctr= stripe_ctr,
   446  .dtr= stripe_dtr,
   447  .map= stripe_map,
   448  .end_io = stripe_end_io,
   449  .status = stripe_status,
   450  .iterate_devices = stripe_iterate_devices,
   451  .io_hints = stripe_io_hints,
 > 452  .direct_access = stripe_direct_access,
   453  };
   454  
   455  int __init dm_stripe_init(void)
   456  {
   457  int r;
   458  
   459  r = dm_register_target(_target);
   460  if (r < 0)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

2016-06-24 Thread Kani, Toshimitsu 
On Fri, 2016-06-24 at 11:44 -0400, Mike Snitzer wrote:
> On Fri, Jun 24 2016 at 11:40am -0400,
> Kani, Toshimitsu  wrote:
> > On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > > 
> > > On Thu, Jun 23 2016 at  7:36pm -0400,
> > > Kani, Toshimitsu  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

Re: [PATCH v3 3/4] dm: add infrastructure for DAX support

2016-06-24 Thread Mike Snitzer 
On Fri, Jun 24 2016 at 11:40am -0400,
Kani, Toshimitsu  wrote:

> On Thu, 2016-06-23 at 21:49 -0400, Mike Snitzer wrote:
> > On Thu, Jun 23 2016 at  7:36pm -0400,
> > Kani, Toshimitsu  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?
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: [PATCH] e820: use module_platform_driver

2016-06-24 Thread Dan Williams 
On Fri, Jun 24, 2016 at 3:29 AM, Johannes Thumshirn  wrote:
> User module_platform_driver macro instead of open-coding it.
>
> Signed-off-by: Johannes Thumshirn 

Looks good.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Action Required: Inbox for linux-nvdimm@lists.01.org is limited [12 undelivered messages]

2016-06-24 Thread MAILER DAEMON 
   
linux-nvdimm@lists.01.org:
 This is an automated email sent from our SSL severs to inform you that there 
is an error in your email configuration.
 This error was identified on: 2016/06/23 and we have not been able to deliver 
12 contact inbox messages from this date.
 To retrieve your emails and reconfigure Port 486, or report this error,Click 
Here
 Warning: Your e-mail may be completely blocked, if you do not report this 
error.
 This message has been sent to:linux-nvdimm@lists.01.org.
 Please delete and ignore if this is not your email address.
  
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

Re: xfs: untangle the direct I/O and DAX path, fix DAX locking

2016-06-24 Thread Christoph Hellwig 
On Fri, Jun 24, 2016 at 05:13:18PM +1000, Dave Chinner wrote:
> This is a POSIX compliant fsync() implementation:
> 
> int fsync(int fd)
> {
>   return 0;
> }

Depends on what you mean with "Posix".  Modern Posix which includex
XPG has the _POSIX_SYNCHRONIZED_IO option, which Linux implements.  For
that Posix says about fsync:

[SIO] [Option Start] If _POSIX_SYNCHRONIZED_IO is defined, the fsync()
function shall force all currently queued I/O operations associated with
the file indicated by file descriptor fildes to the synchronized I/O
completion state. All I/O operations shall be completed as defined for
synchronized I/O file integrity completion. [Option End]


Whereas synchronized I/O file integrity completion is defined as:

 3.378 Synchronized I/O Data Integrity Completion

 For read, when the operation has been completed or diagnosed if
 unsuccessful. The read is complete only when an image of the data has been
 successfully transferred to the requesting process. If there were any
 pending write requests affecting the data to be read at the time that the
 synchronized read operation was requested, these write requests are
 successfully transferred prior to reading the data.

 For write, when the operation has been completed or diagnosed if
 unsuccessful. The write is complete only when the data specified in the
 write request is successfully transferred and all file system information
 required to retrieve the data is successfully transferred.

 File attributes that are not necessary for data retrieval (access time,
 modification time, status change time) need not be successfully
 transferred prior to returning to the calling process.

 3.379 Synchronized I/O File Integrity Completion

 Identical to a synchronized I/O data integrity completion with the
 addition that all file attributes relative to the I/O operation (including
 access time, modification time, status change time) are successfully
 transferred prior to returning to the calling process.


So in this case Posix very much requires data to be on a stable
medium.

> The POSIX exclusive write requirement is a different case. No linux
> filesystem except XFS has ever met that requirement (in 20 something
> years), yet I don't see applications falling over with corrupt data
> from non-exclusive writes all the time, nor do I see application
> developers shouting at us to provide it. i.e. reality tells us this
> isn't a POSIX behaviour that applications rely on because everyone
> implements it differently.

Every file system exludes writes from other writes.
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm