From: Martin Wilck
Hello Mike, hello Martin,
here is v5 of my attempt to add retry logic to SG_IO on dm-multipath
devices.
Christoph's comment on v4 has been received, but as I'm still confused
how to handle the SCSI result / blk_status_t conversion properly, and
waiting for more guidance, I wa
From: Martin Wilck
This helper converts the SCSI result in a sg_io_hdr struct to a blk_status_t.
It will be used in the SG_IO code path for dm-multipath. Putting it into
scsi_ioctl.c avoids open-coding SCSI specific code in the dm layer.
Signed-off-by: Martin Wilck
---
block/scsi_ioctl.c |
From: Martin Wilck
In virtual deployments, SCSI passthrough over dm-multipath devices is a
common setup. The qemu "pr-helper" was specifically invented for it. I
believe that this is the most important real-world scenario for sending
SG_IO ioctls to device-mapper devices.
In this configuration,
From: Martin Wilck
This makes it possible to use scsi_result_to_blk_status() from
code that shouldn't depend on scsi_mod (e.g. device mapper).
scsi_ioctl.c is selected by CONFIG_BLK_SCSI_REQUEST, which is automatically
selected by CONFIG_SCSI.
Signed-off-by: Martin Wilck
---
block/scsi_ioctl.
Hello Christoph,
On Mo, 2021-06-28 at 11:53 +0200, Christoph Hellwig wrote:
> On Mon, Jun 28, 2021 at 11:52:08AM +0200, mwi...@suse.com wrote:
> > From: Martin Wilck
> >
> > This makes it possible to use scsi_result_to_blk_status() from
> > code that shouldn't depend on scsi_mod (e.g. device map
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on scsi/for-next next-20210628]
[cannot apply to dm/for-next block/for-next song-md/md-next v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a
The patch 95b88f4d71cb953e02206be3c757083601391a0f ("dm writecache: pause
writeback if cache full and origin being written directly") introduced a
code that pauses cache flushing if we are issuing writes directly to the
origin.
This patch makes the timeout code configurable (via the option
"pause_
From: Martin Wilck
This makes it possible to use scsi_result_to_blk_status() from
code that shouldn't depend on scsi_mod (e.g. device mapper).
scsi_ioctl.c is selected by CONFIG_BLK_SCSI_REQUEST, which is automatically
selected by CONFIG_SCSI.
Signed-off-by: Martin Wilck
---
block/scsi_ioctl.
From: Martin Wilck
In virtual deployments, SCSI passthrough over dm-multipath devices is a
common setup. The qemu "pr-helper" was specifically invented for it. I
believe that this is the most important real-world scenario for sending
SG_IO ioctls to device-mapper devices.
In this configuration,
From: Martin Wilck
This helper converts the SCSI result in a sg_io_hdr struct to a blk_status_t.
It will be used in the SG_IO code path for dm-multipath. Putting it into
scsi_ioctl.c avoids open-coding SCSI specific code in the dm layer.
Signed-off-by: Martin Wilck
---
block/scsi_ioctl.c |
From: Martin Wilck
Hello Mike, hello Martin,
here is v4 of my attempt to add retry logic to SG_IO on dm-multipath devices.
Regards
Martin
Changes v3->v4 (thanks to Mike Snitzer):
- Added an additional helper function sg_io_to_blk_status() to
scsi_ioctl.c, in order to avoid open-coding han
On Mon, Jun 28, 2021 at 08:02:14AM +0800, Shiyang Ruan wrote:
> +/*
> + * dax_load_pfn - Load pfn of the DAX entry corresponding to a page
> + * @mapping: The file whose entry we want to load
> + * @index: offset where the DAX entry located in
> + *
> + * Return: pfn number of the DAX entry
> +
With dax_holder notify support, we are able to notify the memory failure
from pmem driver to upper layers. If there is something not support in
the notify routine, memory_failure will fall back to the generic hanlder.
Signed-off-by: Shiyang Ruan
---
drivers/nvdimm/pmem.c | 13 +
mm/
On Mon, Jun 28, 2021 at 11:52:08AM +0200, mwi...@suse.com wrote:
> From: Martin Wilck
>
> This makes it possible to use scsi_result_to_blk_status() from
> code that shouldn't depend on scsi_mod (e.g. device mapper).
This really has no business being used outside of low-level SCSI code.
--
dm-de
Since owner tracking is triggerred by pmem device, these functions are
useless. So remove them.
Signed-off-by: Shiyang Ruan
---
fs/dax.c | 46 --
1 file changed, 46 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 7c5d8acd6bc5..cee8e61d1025 100644
change made to resolve following checkpatch message:
WARNING: EXPORT_SYMBOL(foo); should immediately follow its
function/variable
Signed-off-by: Jinchao Wang
---
drivers/md/dm-path-selector.c | 3 +--
drivers/md/dm-target.c| 4 ++--
2 files changed, 3 insertions(+), 4 deletions(-)
dif
When memory-failure occurs, we call this function which is implemented
by each kind of devices. For the fsdax case, pmem device driver
implements it. Pmem device driver will find out the filesystem in which
the corrupted page located in. And finally call filesystem handler to
deal with this erro
This is the case where the holder represents a mapped device, or a list
of mapped devices more exactly(because it is possible to create more
than one mapped device on one pmem device).
Find out which mapped device the offset belongs to, and translate the
offset from target device to mapped device.
This patchset is aimed to support shared pages tracking for fsdax.
Change from V4:
- Add nr_pfns for ->memory_failure() to support range based notification
- Remove struct bdev in dax_holder_notify_failure()
- Add rwsem for dax_holder
- Rename functions to (*_)notify_failure()
- Remove s
This function is used to handle errors which may cause data lost in
filesystem. Such as memory failure in fsdax mode.
If the rmap feature of XFS enabled, we can query it to find files and
metadata which are associated with the corrupt data. For now all we do
is kill processes with that file mapp
On 6/18/21 10:39 PM, Ming Lei wrote:
> From 47e523b9ee988317369eaadb96826323cd86819e Mon Sep 17 00:00:00 2001
> From: Ming Lei
> Date: Wed, 16 Jun 2021 16:13:46 +0800
> Subject: [RFC PATCH V3 3/3] dm: support bio polling
>
> Support bio(REQ_POLLED) polling in the following approach:
>
> 1) onl
memory_failure_dev_pagemap code is a bit complex before introduce RMAP
feature for fsdax. So it is needed to factor some helper functions to
simplify these code.
Signed-off-by: Shiyang Ruan
---
mm/memory-failure.c | 101 +---
1 file changed, 57 insertions
Pmem device could be a target of mapped device. In order to find out
the global location on a mapped device, we introduce this to translate
offset from target device to mapped device.
Currently, we implement it on linear target, which is easy to do the
translation. Other targets will be supporte
This function is called at the end of RMAP routine, i.e. filesystem
recovery function. The difference between mf_generic_kill_procs() is,
mf_dax_kill_procs() accepts file mapping and offset instead of struct
page. It is because that different file mappings and offsets may share
the same page in f
On 6/22/21 10:45 AM, Ming Lei wrote:
> On Tue, Jun 22, 2021 at 10:26:15AM +0800, JeffleXu wrote:
>>
>>
>> On 6/21/21 10:04 PM, Ming Lei wrote:
>>> On Mon, Jun 21, 2021 at 07:33:34PM +0800, JeffleXu wrote:
On 6/18/21 10:39 PM, Ming Lei wrote:
> From 47e523b9ee988317369eaadb9682
To easily track filesystem from a pmem device, we introduce a holder for
dax_device structure, and also its operation. This holder is used to
remember who is using this dax_device:
- When it is the backend of a filesystem, the holder will be the
superblock of this filesystem.
- When this pmem
On Wed, Jun 02 2021 at 15:12, Peter Zijlstra wrote:
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Thomas Gleixner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On 6/21/21 10:04 PM, Ming Lei wrote:
> On Mon, Jun 21, 2021 at 07:33:34PM +0800, JeffleXu wrote:
>>
>>
>> On 6/18/21 10:39 PM, Ming Lei wrote:
>>> From 47e523b9ee988317369eaadb96826323cd86819e Mon Sep 17 00:00:00 2001
>>> From: Ming Lei
>>> Date: Wed, 16 Jun 2021 16:13:46 +0800
>>> Subject: [RF
On 6/19/21 4:56 AM, Mike Snitzer wrote:
> [you really should've changed the subject of this email to
> "[RFC PATCH V3 3/3] dm: support bio polling"]
>
> On Fri, Jun 18 2021 at 10:39P -0400,
> Ming Lei wrote:
>
>> From 47e523b9ee988317369eaadb96826323cd86819e Mon Sep 17 00:00:00 2001
>> From:
On Fri, Jun 18, 2021 at 11:37:28AM +0800, Herbert Xu wrote:
> On Thu, Jun 17, 2021 at 08:01:57PM -0700, Ira Weiny wrote:
> >
> > > + flush_kernel_dcache_page(__page); \
> >
> > Is this required on 32bit systems? Why is kunmap_flush_on_unmap() not
> > sufficient on 64bit syst
On 6/17/21 6:35 PM, Ming Lei wrote:
> Support bio(REQ_POLLED) polling in the following approach:
>
> 1) only support io polling on normal READ/WRITE, and other abnormal IOs
> still fallback on IRQ mode, so the target io is exactly inside the dm
> io.
>
> 2) hold one refcnt on io->io_count afte
31 matches
Mail list logo
