> split and route upper-level bdev_dax_supported() requests.
>
> Fixes: ad428cdb525a ("dax: Check the end of the block-device...")
> Cc:
> Cc: Jan Kara
> Cc: Ira Weiny
> Cc: Dave Jiang
> Cc: Mike Snitzer
> Cc: Keith Busch
> Cc: Matthew Wilcox
>
On Mon, Jun 10 2019 at 5:07am -0400,
Pankaj Gupta wrote:
> This patch sets dax device 'DAXDEV_SYNC' flag if all the target
> devices of device mapper support synchrononous DAX. If device
> mapper consists of both synchronous and asynchronous dax devices,
> we don't set 'DAXDEV_SYNC' flag.
>
On Tue, Jun 11 2019 at 9:10am -0400,
Pankaj Gupta wrote:
> Hi Mike,
>
> Thanks for the review Please find my reply inline.
>
> >
> > dm_table_supports_dax() is called multiple times (from
> > dm_table_set_restrictions and dm_table_determine_type). It is strange
> > to have a getter have a si
27;t set 'DAXDEV_SYNC' flag.
>
> 'dm_table_supports_dax' is refactored to pass 'iterate_devices_fn'
> as argument so that the callers can pass the appropriate functions.
>
> Suggested-by: Mike Snitzer
> Signed-off-by: Pankaj Gupta
Thanks, and for the be
I staged the fix (which I tweaked) here:
https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-5.3&id=95b9ebb78c4c733f8912a195fbd0bc19960e726e
Also, please note this additional related commit that just serves to
improve a related function name and clean up some wh
On Tue, Jul 30 2019 at 5:38pm -0400,
Dan Williams wrote:
> On Tue, Jul 30, 2019 at 12:07 PM Mike Snitzer wrote:
> >
> > I staged the fix (which I tweaked) here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.gi
On Thu, Mar 08 2018 at 12:08pm -0500,
Dan Williams wrote:
> Mikulas sent this useful enhancement to the memcpy_flushcache API:
>
> https://patchwork.kernel.org/patch/10217655/
>
> ...it's in my queue to either push through -tip or add it to the next
> libnvdimm pull request for 4.17-rc1.
H
On Tue, May 22 2018 at 2:39am -0400,
Christoph Hellwig wrote:
> On Sat, May 19, 2018 at 07:25:07AM +0200, Mikulas Patocka wrote:
> > Use new API for flushing persistent memory.
>
> The sentence doesnt make much sense. 'A new API', 'A better
> abstraction' maybe?
>
> >
> > The problem is this
On Tue, May 22 2018 at 3:00pm -0400,
Dan Williams wrote:
> On Tue, May 22, 2018 at 11:41 AM, Mike Snitzer wrote:
> > On Tue, May 22 2018 at 2:39am -0400,
> > Christoph Hellwig wrote:
> >
> >> On Sat, May 19, 2018 at 07:25:07AM +0200, Mikulas Patocka wrote:
&
On Tue, May 22 2018 at 3:27pm -0400,
Dan Williams wrote:
> On Tue, May 22, 2018 at 12:19 PM, Mike Snitzer wrote:
> > On Tue, May 22 2018 at 3:00pm -0400,
> > Dan Williams wrote:
> >
> >> On Tue, May 22, 2018 at 11:41 AM, Mike Snitzer wrote:
> >>
elevated out of this dm-writecache driver. But that can happen
later without requiring DM developers to blaze new trails on pmem
specific implementation details/quirks (pmem developers need to clean up
their APIs given they are already spread across CONFIG_ARCH_HAS_PMEM_API
and CONFIG_ARCH_HAS_UACCESS_
On Thu, May 24 2018 at 10:55pm -0400,
Ross Zwisler wrote:
> Currently the code in dm_dax_direct_access() only checks whether the target
> type has a direct_access() operation defined, not whether the underlying
> block devices all support DAX. This latter property can be seen by looking
> at whe
On Wed, May 30 2018 at 9:07am -0400,
Mikulas Patocka wrote:
>
>
> On Mon, 28 May 2018, Dan Williams wrote:
>
> > On Mon, May 28, 2018 at 6:32 AM, Mikulas Patocka
> > wrote:
> > >
> > > I measured it (with nvme backing store) and late cache flushing has 12%
> > > better performance than eage
On Wed, May 30 2018 at 9:21am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > That is really great news, can you submit an incremental patch that
> > layers ontop of the linux-dm.git 'dm-4.18' branch?
> >
> &g
On Wed, May 30 2018 at 9:33am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > On Wed, May 30 2018 at 9:21am -0400,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Wed, 30 May 2018, Mike Sni
On Wed, May 30 2018 at 10:09am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > On Wed, May 30 2018 at 9:33am -0400,
> > Mikulas Patocka wrote:
> >
> > >
> > >
> > > On Wed, 30 May 2018, Mike Sni
On Wed, May 30 2018 at 10:09P -0400,
Mikulas Patocka wrote:
> And what about this?
> #define WC_MODE_PMEM(wc)((wc)->pmem_mode)
>
> The code that I had just allowed the compiler to optimize out
> persistent-memory code if we have DM_WRITECACHE_ONLY_SSD defined - and you
On Wed, May 30 2018 at 10:46P -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > > > Fine I'll deal with it. reordering the fields eliminated holes in the
> > > > structure and reduced struct members spanning cach
On Thu, May 31 2018 at 4:16am -0400,
Mikulas Patocka wrote:
>
>
> On Wed, 30 May 2018, Mike Snitzer wrote:
>
> > On Wed, May 30 2018 at 10:09P -0400,
> > Mikulas Patocka wrote:
> >
> > > And what about this?
> > > #define WC_MODE_
On Thu, May 31 2018 at 3:13pm -0400,
Darrick J. Wong wrote:
> On Tue, May 29, 2018 at 04:01:14PM -0600, Ross Zwisler wrote:
> > On Tue, May 29, 2018 at 02:25:10PM -0700, Darrick J. Wong wrote:
> > > On Tue, May 29, 2018 at 01:51:01PM -0600, Ross Zwisler wrote:
> > > > From: Dave Jiang
> > > >
On Tue, May 29 2018 at 3:51P -0400,
Ross Zwisler wrote:
> Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX
> flag is set on the device's request queue to decide whether or not the
> device supports filesystem DAX. This is insufficient because there are
> devices like PME
On Fri, Jun 01 2018 at 4:19P -0400,
Mike Snitzer wrote:
> On Tue, May 29 2018 at 3:51P -0400,
> Ross Zwisler wrote:
>
> > Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX
> > flag is set on the device's request queue to decide whether or n
On Tue, May 29 2018 at 3:51pm -0400,
Ross Zwisler wrote:
> Currently the code in dm_dax_direct_access() only checks whether the target
> type has a direct_access() operation defined, not whether the underlying
> block devices all support DAX. This latter property can be seen by looking
> at whe
On Tue, May 29 2018 at 3:51pm -0400,
Ross Zwisler wrote:
> The DM_TYPE_DAX_BIO_BASED dm_queue_mode was introduced to prevent DM
> devices that could possibly support DAX from transitioning into DM devices
> that cannot support DAX.
>
> For example, the following transition will currently fail:
On Mon, Jun 04 2018 at 7:40pm -0400,
Dan Williams wrote:
> On Sun, Jun 3, 2018 at 6:48 PM, Dan Williams wrote:
> > On Sun, Jun 3, 2018 at 5:25 PM, Dave Chinner wrote:
> >> On Mon, Jun 04, 2018 at 08:20:38AM +1000, Dave Chinner wrote:
> >>> On Thu, May 31, 2018 at 09:02:52PM -0700, Dan Williams
On Mon, Jun 04 2018 at 7:24pm -0400,
Ross Zwisler wrote:
> On Fri, Jun 01, 2018 at 06:04:43PM -0400, Mike Snitzer wrote:
> > On Tue, May 29 2018 at 3:51pm -0400,
> > Ross Zwisler wrote:
> >
> > > The DM_TYPE_DAX_BIO_BASED dm_queue_mode was introduced to preve
On Wed, Jun 06 2018 at 1:24P -0400,
Ross Zwisler wrote:
> On Mon, Jun 04, 2018 at 08:46:28PM -0400, Mike Snitzer wrote:
> > On Mon, Jun 04 2018 at 7:24pm -0400,
> > Ross Zwisler wrote:
> >
> > > On Fri, Jun 01, 2018 at 06:04:43PM -0400, Mike Snitzer wrote:
>
On Mon, Jun 18 2018 at 8:50am -0400,
Mikulas Patocka wrote:
> Hi Mike
>
> Could you please push this patch to the kernel 4.18-rc? Dan Williams said
> that he will submit it, but he forgot about it.
>
> Without this patch, dm-writecache is suffering 2% penalty because of
> memcpy_flushcache o
On Mon, Jun 04 2018 at 7:15pm -0400,
Ross Zwisler wrote:
> On Fri, Jun 01, 2018 at 05:55:13PM -0400, Mike Snitzer wrote:
> > On Tue, May 29 2018 at 3:51pm -0400,
> > Ross Zwisler wrote:
> >
> > > Currently the code in dm_dax_direct_access() only checks whethe
On Tue, Jun 26 2018 at 1:59pm -0400,
Ross Zwisler wrote:
> Currently device_supports_dax() just checks to see if the QUEUE_FLAG_DAX
> flag is set on the device's request queue to decide whether or not the
> device supports filesystem DAX. Really we should be using
> bdev_dax_supported() like fi
On Tue, Jun 26 2018 at 1:59pm -0400,
Ross Zwisler wrote:
> This series fixes a few issues that I found with DM's handling of DAX
> devices. Here are some of the issues I found:
>
> * We can create a dm-stripe or dm-linear device which is made up of an
>fsdax PMEM namespace and a raw PMEM
"
> > or "sector" modes. These namespaces lack struct page and are prevented
> > from participating in filesystem DAX.
> >
> > Signed-off-by: Ross Zwisler
> > Suggested-by: Mike Snitzer
> > Cc: sta...@vger.kernel.org
>
> Why is this cc: stable? W
On Tue, Jun 26 2018 at 3:07pm -0400,
Dan Williams wrote:
> On Tue, Jun 26, 2018 at 11:58 AM, Mike Snitzer wrote:
> > On Tue, Jun 26 2018 at 2:52pm -0400,
> > Dan Williams wrote:
> >
> >> On Tue, Jun 26, 2018 at 10:59 AM, Ross Zwisler
> >> wrote:
> &
On Thu, Jun 28 2018 at 1:42pm -0400,
Kani, Toshi wrote:
> On Tue, 2018-06-26 at 16:04 -0600, Ross Zwisler wrote:
> > On Tue, Jun 26, 2018 at 02:51:52PM -0700, Dan Williams wrote:
> > > On Tue, Jun 26, 2018 at 2:31 PM, Kani, Toshi wrote:
> > > > On Tue, 2018-06-26 at 14:28 -0700, Dan Williams wr
then just throw away.
>
> Suggested-by: Ross Zwisler
> Signed-off-by: Huaisheng Ye
Acked-by: Mike Snitzer
___
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
On Tue, Aug 28 2018 at 3:50am -0400,
Jan Kara wrote:
> On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
> > On Mon, 2018-08-27 at 18:07 +0200, Jan Kara wrote:
> > > Hi,
> > >
> > > I've been analyzing why fstest generic/081 fails when the backing device
> > > is
> > > capable of DAX. The problem b
On Thu, Aug 30 2018 at 5:30am -0400,
Jan Kara wrote:
> On Tue 28-08-18 13:56:30, Mike Snitzer wrote:
> > On Tue, Aug 28 2018 at 3:50am -0400,
> > Jan Kara wrote:
> >
> > > On Mon 27-08-18 16:43:28, Kani, Toshi wrote:
> > > > On Mon, 2018-08-27 at
On Wed, Dec 12 2018 at 11:12am -0500,
Christoph Hellwig wrote:
> Does it really make sense to enhance dm-snapshot? I thought all serious
> users of snapshots had moved on to dm-thinp?
There are cases where dm-snapshot is still useful for people. But those
are very niche users. I'm not opposed
On Wed, Dec 12 2018 at 4:15pm -0500,
Theodore Y. Ts'o wrote:
> On Wed, Dec 12, 2018 at 12:50:47PM -0500, Mike Snitzer wrote:
> > On Wed, Dec 12 2018 at 11:12am -0500,
> > Christoph Hellwig wrote:
> >
> > > Does it really make sense to enhance dm-snapshot? I
On Fri, Dec 14 2018 at 3:24am -0500,
Huaisheng HS1 Ye wrote:
> From: Mike Snitzer
> Sent: Thursday, December 13, 2018 6:43 AM
> > On Wed, Dec 12 2018 at 4:15pm -0500,
> > Theodore Y. Ts'o wrote:
> >
> > > On Wed, Dec 12, 2018 at 12:50:47PM -0500, Mike
ier, but could you take a look at
> this patch and ack it if it looks ok to go through the nvdimm tree
> with the rest of the series?
Yes, looks fine to me.
Acked-by: Mike Snitzer
___
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsub
On Tue, Jun 30 2020 at 10:10am -0400,
Michal Suchánek wrote:
> On Tue, Jun 30, 2020 at 09:32:01AM -0400, Mikulas Patocka wrote:
> >
> >
> > On Tue, 30 Jun 2020, Michal Suchanek wrote:
> >
> > > The writecache driver does not handle asynchronous pmem. Reject it when
> > > supplied as cache.
> >
On Wed, Jul 01 2020 at 4:59am -0400,
Christoph Hellwig wrote:
> Instead of setting up the queuedata as well just use one private data
> field.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Mike Snitzer
___
Linux-nvdimm mailing l
On Wed, Aug 02 2017 at 1:58pm -0400,
Dan Williams wrote:
> Rather than have device-mapper directly 'select DAX', let the fact that
> BLK_DEV_PMEM selects dax act as a gate for the device-mapper dax
> support. We arrange for all the dax core routines to compile to nops
> when CONFIG_DAX=n. With t
On Fri, Oct 20 2017 at 1:24am -0400,
Ross Zwisler wrote:
> Currently dm-log-writes supports writing filesystem data via BIOs, and
> writing internal metadata from a flat buffer via write_metadata().
>
> For DAX writes, though, we won't have a BIO, but will instead have an
> iterator that we'll
On Fri, Oct 20 2017 at 1:24am -0400,
Ross Zwisler wrote:
> Now that we have the ability log filesystem writes using a flat buffer, add
> support for DAX. Unfortunately we can't easily track data that has been
> written via mmap() now that the dax_flush() abstraction was removed by this
> commit
On Wed, Nov 29 2017 at 1:59pm -0500,
Dan Williams wrote:
> Changes since v5 [1]:
> * Make DAX_DRIVER select DAX to simplify the Kconfig dependencies
> (Michael)
> * Rebase on 4.15-rc1 and add new IS_ENABLED(CONFIG_DAX_DRIVER) checks in
> drivers/md/dm-log-writes.c.
>
> [1]: https://lists.01
On Sun, Jan 07 2018 at 3:31pm -0500,
Dan Williams wrote:
> On Thu, Jan 4, 2018 at 10:12 AM, Mike Snitzer wrote:
> > On Wed, Nov 29 2017 at 1:59pm -0500,
> > Dan Williams wrote:
> >
> >> Changes since v5 [1]:
> >> * Make DAX_DRIVER select D
yered on top. This allows device-mapper to conditionally 'select DAX'
> only when a provider is present.
>
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: Martin Schwidefsky
> Cc: Heiko Carstens
> Cc: Gerald Schaefer
> Cc: Benjamin Herrenschmidt
> Cc: Mik
DAX drivers, like BLK_DEV_PMEM, configured.
>
> Cc: Alasdair Kergon
> Cc: Mike Snitzer
> Reported-by: Bart Van Assche
> Reported-by: kbuild test robot
> Signed-off-by: Dan Williams
Reviewed-by: Mike Snitzer
___
Linux-nvdimm mai
> > although that implementation is saved for a later patch.
> >
> > Cc: Alasdair Kergon
> > Cc: Mike Snitzer
>
> Mike, do these DM touches look ok to you? We need these ->fs_claim()
> / ->fs_release() interfaces for device-mapper to set up filesystem-d
MA is in-flight and then
> resume those operations when the last put_page() occurs on a DMA page.
> The ->fs_claim() operation arranges for this callback to be registered,
> although that implementation is saved for a later patch.
>
> Cc: Alasdair Kergon
> Cc: Mike Snitzer
&
5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
__generic_fsdax_supported()") switched from pr_debug() to pr_info().
The justification in the commit header is really inadequate. If there
is a problem that you need to drill in on, repeat the testing after
enabling the dynamic d
On Wed, Sep 02 2020 at 12:40pm -0400,
Coly Li wrote:
> On 2020/9/3 00:04, Mike Snitzer wrote:
> > 5.9 commit 231609785cbfb ("dax: print error message by pr_info() in
> > __generic_fsdax_supported()") switched from pr_debug() to pr_info().
> >
> > The justifi
On Wed, Sep 02 2020 at 12:46pm -0400,
Coly Li wrote:
> On 2020/9/3 00:44, Mike Snitzer wrote:
> > On Wed, Sep 02 2020 at 12:40pm -0400,
> > Coly Li wrote:
> >
> >> On 2020/9/3 00:04, Mike Snitzer wrote:
> >>> 5.9 commit 231609785cbfb
!bdev_dax_supported(bdev, blocksize)) {
Don't think I've ever seen a one-liner fix document the diff in its
patch header. Really no need for that.
> Fixes: c2affe920b0e ("dax: do not print error message for non-persistent
> memory block device")
> Signed-off-by: Coly Li
On Tue, Sep 15 2020 at 3:49pm -0400,
Dan Williams wrote:
> On Tue, Sep 15, 2020 at 1:01 AM Jan Kara wrote:
> >
> > Hi!
> >
> > On Tue 15-09-20 11:03:29, col...@suse.de wrote:
> > > Could you please to take a look? I am offline in the next two weeks.
> >
> > I just had a look into this. IMHO the
e a DM device was stacked on top of
> another DM device.
>
> Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple
> devices")
> Tested-by: Adrian Huang
> Signed-off-by: Jan Kara
Looked good:
Acked-by: Mike Snitzer
This fix should Cc stable@ ri
Hey Dan,
On Fri, Oct 16, 2020 at 6:38 PM Dan Williams wrote:
>
> On Fri, Oct 16, 2020 at 2:59 PM Nabeel Meeramohideen Mohamed
> (nmeeramohide) wrote:
>
> > (5) Representing an mpool as a /dev/mpool/ device file provides
> > a
> > convenient mechanism for controlling access to and managing the m
duced to separate some of
> > the dm-specifics from the direct_access implementation.
> >
> > This enabling is only for the top-level dm representation to upper
> > layers. Converting target direct_access implementations is deferred to a
> > separate patch.
> &g
On Tue, Jul 25 2017 at 3:43pm -0400,
Vivek Goyal wrote:
> Right now, dm_dax_flush() is not being called and I think it is not being
> called becuase DAXDEV_WRITE_CACHE is not set on dm dax device.
>
> If underlying dax device supports write cache, set DAXDEV_WRITE_CACHE on
> dm dax device. This
On Wed, Jul 26 2017 at 9:35am -0400,
Vivek Goyal wrote:
> Right now, dm_dax_flush() is not being called and I think it is not being
> called becuase DAXDEV_WRITE_CACHE is not set on dm dax device.
>
> If underlying dax device supports write cache, set DAXDEV_WRITE_CACHE on
> dm dax device. This
On Fri, Jul 28 2017 at 12:17pm -0400,
Bart Van Assche wrote:
> On Mon, 2017-04-17 at 12:09 -0700, Dan Williams wrote:
> > diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
> > index b7767da50c26..1de8372d9459 100644
> > --- a/drivers/md/Kconfig
> > +++ b/drivers/md/Kconfig
> > @@ -200,6 +200,7
the dax operations helpers are moved to a new file,
> drivers/md/dm-dax.c, that is optionally compiled when CONFIG_DM_DAX=y.
> Otherwise, we stub out all the operations with NULL function pointers
> and nop wrappers for the core dax routines.
>
> Cc: Alasdair Kergon
> Cc: Mike Sni
On Wed, Aug 02 2017 at 1:57pm -0400,
Dan Williams wrote:
> Changes since v2 [1]:
> * rebase on -next to integrate with commit 273752c9ff03 "dm, dax: Make
> sure dm_dax_flush() is called if device supports it" (kbuild robot)
> * fix CONFIG_DAX dependencies to upgrade CONFIG_DAX=m to CONFIG_DAX=
On Mon, Jun 13 2016 at 6:57pm -0400,
Mike Snitzer wrote:
> On Mon, Jun 13 2016 at 6:21pm -0400,
> Toshi Kani wrote:
>
> > This patch-set adds DAX support to device-mapper dm-linear devices
> > used by LVM. It works with LVM commands as follows:
> > - Creation o
On Mon, Jun 20 2016 at 2:31pm -0400,
Kani, Toshimitsu wrote:
> On Mon, 2016-06-20 at 14:00 -0400, Mike Snitzer wrote:
> >
> > I rebased your patches on linux-dm.git's 'for-next' (which includes what
> > I've already staged for the 4.8 merge window).
On Mon, Jun 20 2016 at 3:40pm -0400,
Mike Snitzer wrote:
> # dd if=/dev/zero of=/mnt/dax/meh bs=1024K oflag=direct
> [11729.754671] XFS (dm-4): Metadata corruption detected at
> xfs_agf_read_verify+0x70/0x120 [xfs], xfs_agf block 0x45a808
> [11729.766423] XFS (dm-4): Unm
On Mon, Jun 20 2016 at 5:28pm -0400,
Kani, Toshimitsu wrote:
> On Mon, 2016-06-20 at 14:01 -0600, Kani, Toshimitsu wrote:
> > On Mon, 2016-06-20 at 15:52 -0400, Mike Snitzer wrote:
> > >
> > > On Mon, Jun 20 2016 at 3:40pm -0400,
> > > Mike Snitzer wrote:
On Mon, Jun 20 2016 at 6:22pm -0400,
Mike Snitzer wrote:
> On Mon, Jun 20 2016 at 5:28pm -0400,
> Kani, Toshimitsu wrote:
>
> >
> > Hi Mike,
> >
> > Can you fold the following patch to the dm-linear patch?
> >
> > Thanks,
> > -Tsohi
On Tue, Jun 21 2016 at 11:44am -0400,
Kani, Toshimitsu wrote:
> On Tue, 2016-06-21 at 09:41 -0400, Mike Snitzer wrote:
> > On Mon, Jun 20 2016 at 6:22pm -0400,
> > Mike Snitzer wrote:
> > >
> > > On Mon, Jun 20 2016 at 5:28pm -0400,
> > > Kani, Toshi
On Wed, Jun 22 2016 at 4:16P -0400,
Kani, Toshimitsu wrote:
> On Wed, 2016-06-22 at 12:15 -0700, Dan Williams wrote:
> > On Wed, Jun 22, 2016 at 10:44 AM, Kani, Toshimitsu
> > wrote:
> > > On Tue, 2016-06-21 at 14:17 -0400, Mike Snitzer wrote:
> > > >
&g
Jens, please pick up the first 2 block patches and I'll get the other
2 DM patches staged for 4.8.
v3:
- fixed "warning: context imbalance in 'dm_blk_direct_access' -
different lock contexts for basic block" due to missing
dm_put_live_table in dm_blk_direct_access's dm_get_live_table error
ice-mapper devices, add
QUEUE_FLAG_DAX to request_queue flags to advertise their DAX
support. This will allow to set the DAX capability based on how
mapped device is composed.
Signed-off-by: Toshi Kani
Acked-by: Dan Williams
Signed-off-by: Mike Snitzer
Cc: Jens Axboe
Cc: Ross Zwisler
From: Toshi Kani
Change dm-linear to implement direct_access function,
linear_direct_access(), which maps sector and calls direct_access
function of its physical target device.
Signed-off-by: Toshi Kani
Signed-off-by: Mike Snitzer
Cc: Alasdair Kergon
Cc: Dan Williams
Cc: Ross Zwisler
t table load to the
mapped device must have the same type, or else it fails per the check in
table_load().
Signed-off-by: Toshi Kani
Signed-off-by: Mike Snitzer
Cc: Alasdair Kergon
Cc: Dan Williams
Cc: Ross Zwisler
---
drivers/md/dm-table.c | 44
On Thu, Jun 23 2016 at 1:36pm -0400,
Kani, Toshimitsu wrote:
> On Thu, 2016-06-23 at 19:31 +0300, Yigal Korman wrote:
> > On Thu, Jun 23, 2016 at 2:54 AM, Toshi Kani wrote:
> > >
> > >
> > > Currently, presence of direct_access() in block_device_operations
> > > indicates support of DAX on it
From: Yigal Korman
Provides the ability to identify DAX enabled devices in userspace.
Signed-off-by: Yigal Korman
Signed-off-by: Toshi Kani
Acked-by: Dan Williams
Signed-off-by: Mike Snitzer
---
block/blk-sysfs.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/block/blk
On Thu, Jun 23 2016 at 7:36pm -0400,
Kani, Toshimitsu wrote:
> On Thu, 2016-06-23 at 17:05 -0400, Mike Snitzer wrote:
> :
> > +static int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
> > + sector_t start, sector_t len, void *data)
>
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. T
On Fri, Jun 24 2016 at 2:23pm -0400,
Toshi Kani wrote:
> Change dm-stripe to implement direct_access function,
> stripe_direct_access(), which maps bdev and sector and
> calls direct_access function of its physical target device.
>
> Signed-off-by: Toshi Kani
> Cc: Alasdair Kergon
> Cc: Dan W
On Fri, Jun 24 2016 at 3:58pm -0400,
kbuild test robot wrote:
> 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://
On Tue, Jun 28 2016 at 3:37pm -0400,
Toshi Kani wrote:
> Allow table type DM_TYPE_BIO_BASED to extend with
> DM_TYPE_DAX_BIO_BASED since DM_TYPE_DAX_BIO_BASED
> supports bio-based requests.
>
> Signed-off-by: Toshi Kani
> Cc: Mike Snitzer
> Cc: Alasdair Kergo
On Tue, Jun 28 2016 at 4:23pm -0400,
Kani, Toshimitsu wrote:
> On Tue, 2016-06-28 at 16:07 -0400, Mike Snitzer wrote:
> > On Tue, Jun 28 2016 at 3:37pm -0400,
> > Toshi Kani wrote:
> :
> > You said in the 0th header: "Patch 1 solves an error when lvremove is
On Thu, Jun 23 2016 at 5:05pm -0400,
Mike Snitzer wrote:
> Jens, please pick up the first 2 block patches and I'll get the other
> 2 DM patches staged for 4.8.
Hey Jens,
Looks like you're back so I figured I'd ping you on these first 2 block
patches again. Can you pick
On Thu, Jun 30 2016 at 1:00pm -0400,
Mike Snitzer wrote:
> On Thu, Jun 23 2016 at 5:05pm -0400,
> Mike Snitzer wrote:
>
> > Jens, please pick up the first 2 block patches and I'll get the other
> > 2 DM patches staged for 4.8.
>
> Hey Jens,
>
> Looks
On Tue, Jul 12 2016 at 6:22pm -0400,
Kani, Toshimitsu wrote:
> On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote:
> >
> > BTW, if in your testing you could evaluate/quantify any extra overhead
> > from DM that'd be useful to share. It could be there are bottl
On Wed, Jul 13 2016 at 11:03am -0400,
Kani, Toshimitsu wrote:
> On Tue, 2016-07-12 at 22:01 -0400, Mike Snitzer wrote:
> > On Tue, Jul 12 2016 at 6:22pm -0400,
> > Kani, Toshimitsu wrote:
> > > On Fri, 2016-06-24 at 14:29 -0400, Mike Snitzer wrote:
> > > >
88 matches
Mail list logo
