Delivery reports about your e-mail

2018-01-17 Thread Bounced mail 
˜æÔ]MiÀÃÐOžP™Ù˜„¾4ŠÓ8وŸ>®Èƒ ô‚s‘†«¤éŒÆâ܊„O9ï‘è¢
Ž´Eþ©¢Šð¦\bJ…¥ðˆî«PA¬«%þn#xF¢pŸ4h5×°v7¸SŸ¤k3]¯Ì4ß¡šFäS•ÐO“ 
ŒÃ/ãqǽS¹ÙSM¿%¼ºòyO 4ÚàpeNÔ®

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

Re: [fstests PATCH 2/2] generic/347: dm-thin lacks DAX support

2018-01-17 Thread Eryu Guan 
On Wed, Jan 17, 2018 at 04:23:51PM -0700, Ross Zwisler wrote:
> generic/347 currently fails when run in cojunction with the DAX mount
> option:
> 
> generic/347 72s ... - output mismatch (see
> /root/project/xfstests/results//generic/347.out.bad)
> --- tests/generic/347.out 2016-05-12 11:56:32.086618744 -0600
> +++ /root/project/xfstests/results//generic/347.out.bad   2018-01-17
> 16:04:33.459348448 -0700
> @@ -1,2 +1,3 @@
>  QA output created by 347
> +mount: /mnt/xfstests_scratch: can't read superblock on
> /dev/mapper/thin-vol.
>  === completed
> ...
> (Run 'diff -u tests/generic/347.out
> /root/project/xfstests/results//generic/347.out.bad'  to see the entire
> diff)
> 
> This is expected because the dm-thin target currently lacks DAX support.
> 
> Just skip this test if we are using DAX.
> 
> Signed-off-by: Ross Zwisler 
> ---
>  tests/generic/347 | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/generic/347 b/tests/generic/347
> index 3adc6744..0c2dec98 100755
> --- a/tests/generic/347
> +++ b/tests/generic/347
> @@ -72,6 +72,7 @@ _supported_fs generic
>  _supported_os Linux
>  _require_scratch_nocheck
>  _require_dm_target thin-pool
> +_exclude_scratch_mount_option dax

IMHO, it'd be better to put this in common/dmthin file, as what's done
in common/dmerror or common/dmflakey (we grep for dax directly there,
that's because they've been added before _exclude_scratch_mount_option
was introduced), so all thinp tests are excluded from dax tests.

Thanks,
Eryu

>  
>  _setup_thin
>  _workout
> -- 
> 2.14.3
> 
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

[fstests PATCH 1/2] shared/272: don't use data journaling with DAX

2018-01-17 Thread Ross Zwisler 
shared/272 fails with kernels v4.15-rc1 and beyond when you are mounted
with DAX:

shared/272   [failed, exit status 1] - output mismatch (see
/root/project/xfstests/results//shared/272.out.bad)
--- tests/shared/272.out2015-12-05 13:12:17.038257578 -0700
+++ /root/project/xfstests/results//shared/272.out.bad  2018-01-17
15:37:18.581631116 -0700
@@ -1,3 +1,3 @@
 QA output created by 272
 Switch data journalling mode. Silence is golden.
-Check filesystem
+/usr/bin/chattr: Device or resource busy while setting flags on
/mnt/xfstests_scratch/file.1
...
(Run 'diff -u tests/shared/272.out
/root/project/xfstests/results//shared/272.out.bad'  to see the entire
diff)

This is expected.  The following kernel commit:

commit e9072d859df3 ("ext4: prevent data corruption with journaling + DAX")

makes "chattr +j", which is attempting to turn on data journaling, return
-EBUSY if the ext4 DAX mount option is in use.  This was done to prevent
the data corruption shown in xfstest ext4/030, added by this xfstests
commit:

commit 750a24e99e48 ("ext4: test for DAX + journaling corruption")

So, just skip shared/272 if the DAX mount option is in use.

Signed-off-by: Ross Zwisler 
---
 tests/shared/272 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/shared/272 b/tests/shared/272
index 7023b657..0c9763df 100755
--- a/tests/shared/272
+++ b/tests/shared/272
@@ -83,6 +83,7 @@ chattr_opt: $chattr_opt" >>$seqres.full
 _supported_fs ext3 ext4
 _supported_os Linux
 _require_scratch
+_exclude_scratch_mount_option dax
 
 rm -f $seqres.full
 _scratch_mkfs_sized $((64 * 1024 * 1024)) >> $seqres.full 2>&1
-- 
2.14.3

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

[fstests PATCH 2/2] generic/347: dm-thin lacks DAX support

2018-01-17 Thread Ross Zwisler 
generic/347 currently fails when run in cojunction with the DAX mount
option:

generic/347 72s ... - output mismatch (see
/root/project/xfstests/results//generic/347.out.bad)
--- tests/generic/347.out   2016-05-12 11:56:32.086618744 -0600
+++ /root/project/xfstests/results//generic/347.out.bad 2018-01-17
16:04:33.459348448 -0700
@@ -1,2 +1,3 @@
 QA output created by 347
+mount: /mnt/xfstests_scratch: can't read superblock on
/dev/mapper/thin-vol.
 === completed
...
(Run 'diff -u tests/generic/347.out
/root/project/xfstests/results//generic/347.out.bad'  to see the entire
diff)

This is expected because the dm-thin target currently lacks DAX support.

Just skip this test if we are using DAX.

Signed-off-by: Ross Zwisler 
---
 tests/generic/347 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/generic/347 b/tests/generic/347
index 3adc6744..0c2dec98 100755
--- a/tests/generic/347
+++ b/tests/generic/347
@@ -72,6 +72,7 @@ _supported_fs generic
 _supported_os Linux
 _require_scratch_nocheck
 _require_dm_target thin-pool
+_exclude_scratch_mount_option dax
 
 _setup_thin
 _workout
-- 
2.14.3

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

[ndctl PATCH] ndctl, test: fix stale json in btt-pad-compat.sh

2018-01-17 Thread Vishal Verma 
We weren't using the updated results of any but the first of the ndctl
create-namespace commands. This could potentially result in the test
being unreliable.

Use the json being emitted by the create-namespace commands to get the
device etc. for future operations. Also do a 'reset' before attempting
the old format restoration test.

Cc: Dan Williams 
Signed-off-by: Vishal Verma 
---
 test/btt-pad-compat.sh | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Dan - If it is easier, I can send a patch for just adding the final
version of this test as a standalone patch. So far there have been three
patches (including this) that touch this test. This one if a minor
bugfix, so it could also be squashed with the first patch where this is
introduced.

diff --git a/test/btt-pad-compat.sh b/test/btt-pad-compat.sh
index d10efe3..129401b 100755
--- a/test/btt-pad-compat.sh
+++ b/test/btt-pad-compat.sh
@@ -144,14 +144,14 @@ copy_xxd_img()
 create_oldfmt_ns()
 {
# create null-uuid namespace
-   $ndctl create-namespace -b "$bus" -t pmem -m raw -l 4096 -u 
----
+   json=$($ndctl create-namespace -b "$bus" -t pmem -m raw -l 4096 -u 
----)
eval "$(echo "$json" | sed -e "$json2var")"
[ -n "$dev" ] || err "$LINENO" 2
[ -n "$size" ] || err "$LINENO" 2
[ $size -gt 0 ] || err "$LINENO" 2
 
# reconfig it to sector mode
-   $ndctl create-namespace -b "$bus" -e $dev -m sector --force
+   json=$($ndctl create-namespace -b "$bus" -e $dev -m sector --force)
eval "$(echo "$json" | sed -e "$json2var")"
[ -n "$dev" ] || err "$LINENO" 2
[ -n "$size" ] || err "$LINENO" 2
@@ -185,6 +185,7 @@ do_tests()
verify_idx 0 1
 
# do the same with an old format namespace
+   reset
create_oldfmt_ns
verify_idx 0 2
 
-- 
2.14.3

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

Re: KVM "fake DAX" flushing interface - discussion

2018-01-17 Thread Pankaj Gupta 

Hi Dan,

Thanks for your reply.

> 
> On Fri, Jan 12, 2018 at 10:23 PM, Pankaj Gupta  wrote:
> >
> > Hello Dan,
> >
> >> Not a flag, but a new "Address Range Type GUID". See section "5.2.25.2
> >> System Physical Address (SPA) Range Structure" in the ACPI 6.2A
> >> specification. Since it is a GUID we could define a Linux specific
> >> type for this case, but spec changes would allow non-Linux hypervisors
> >> to advertise a standard interface to guests.
> >>
> >
> > I have added new SPA with a GUUID for this memory type and I could add
> > this new memory type in System memory map. I need help with the namespace
> > handling for this new type As mentioned in [1] discussion:
> >
> > - Create a new namespace for this new memory type
> > - Teach libnvdimm how to handle this new namespace
> >
> > I have some queries on this:
> >
> > 1] How namespace handling of this new memory type would be?
> 
> This would be a namespace that creates a pmem device, but does not allow DAX.

o.k

> 
> >
> > 2] There are existing namespace types:
> >   ND_DEVICE_NAMESPACE_IO, ND_DEVICE_NAMESPACE_PMEM, ND_DEVICE_NAMESPACE_BLK
> >
> >   How libnvdimm will handle this new name-space type in conjuction with
> >   existing
> >   memory type, region & namespaces?
> 
> The type will be either ND_DEVICE_NAMESPACE_IO or
> ND_DEVICE_NAMESPACE_PMEM depending on whether you configure KVM to
> provide a virtual NVDIMM and label space. In other words the only
> difference between this range and a typical persistent memory range is
> that we will have a flag to disable DAX operation.

o.k. In short we have disable this flag 'QUEUE_FLAG_DAX' for this 
namespace & region? Also don't execute below code for this new type?

pmem_attach_disk()
...
...
dax_dev = alloc_dax(pmem, disk->disk_name, _dax_ops);
if (!dax_dev) {
put_disk(disk);
return -ENOMEM;
}
dax_write_cache(dax_dev, wbc);
pmem->dax_dev = dax_dev;

> 
> See the usage of nvdimm_has_cache() in pmem_attach_disk() as an
> example of how to pass attributes about the "region" to the the pmem
> driver.

sure.

> 
> >
> > 3] For sending guest to host flush commands we still have to think about
> > some
> >async way?
> 
> I thought we discussed this being a paravirtualized virtio command ring?

o.k. will implement this. 

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

Re: KVM "fake DAX" flushing interface - discussion

2018-01-17 Thread Dan Williams 
On Fri, Jan 12, 2018 at 10:23 PM, Pankaj Gupta  wrote:
>
> Hello Dan,
>
>> Not a flag, but a new "Address Range Type GUID". See section "5.2.25.2
>> System Physical Address (SPA) Range Structure" in the ACPI 6.2A
>> specification. Since it is a GUID we could define a Linux specific
>> type for this case, but spec changes would allow non-Linux hypervisors
>> to advertise a standard interface to guests.
>>
>
> I have added new SPA with a GUUID for this memory type and I could add
> this new memory type in System memory map. I need help with the namespace
> handling for this new type As mentioned in [1] discussion:
>
> - Create a new namespace for this new memory type
> - Teach libnvdimm how to handle this new namespace
>
> I have some queries on this:
>
> 1] How namespace handling of this new memory type would be?

This would be a namespace that creates a pmem device, but does not allow DAX.

>
> 2] There are existing namespace types:
>   ND_DEVICE_NAMESPACE_IO, ND_DEVICE_NAMESPACE_PMEM, ND_DEVICE_NAMESPACE_BLK
>
>   How libnvdimm will handle this new name-space type in conjuction with 
> existing
>   memory type, region & namespaces?

The type will be either ND_DEVICE_NAMESPACE_IO or
ND_DEVICE_NAMESPACE_PMEM depending on whether you configure KVM to
provide a virtual NVDIMM and label space. In other words the only
difference between this range and a typical persistent memory range is
that we will have a flag to disable DAX operation.

See the usage of nvdimm_has_cache() in pmem_attach_disk() as an
example of how to pass attributes about the "region" to the the pmem
driver.

>
> 3] For sending guest to host flush commands we still have to think about some
>async way?

I thought we discussed this being a paravirtualized virtio command ring?
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm