On Fri, 15 Oct 2021 16:30:19 -0700, Luis Chamberlain wrote:
> Jens,
>
> I had last split up patches into 7 groups, but at this point now
> most changes are merged except a few more drivers. Instead of creating
> a new patch set for each of the 7 groups I'm creating 3 new groups of
> patches now:
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Friday, October 15, 2021 10:11 PM
> On Fri, Oct 15, 2021 at 12:25:53PM -0700, Deven Bowers wrote:
> >
> > On 10/13/2021 12:24 PM, Eric Biggers wrote:
> > > On Wed, Oct 13, 2021 at 12:06:31PM -0700,
> deven.de...@linux.microsoft.com wrote:
>
When DAXDEV_F_RECOVERY flag is set, pmem_copy_to_iter() shall read
as much data as possible up till the first poisoned page is
encountered, and pmem_copy_from_iter() shall try to clear poison(s)
within the page aligned range prior to writing.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 7
Prepare dax_copy_to/from_iter() APIs with DAXDEV_F_RECOVERY flag
such that when the flag is set, the underlying driver implementation
of the APIs may deal with potential poison in a given address
range and read partial data or write after clearing poison.
Signed-off-by: Jane Chu
---
drivers/dax/
dm_dax_direct_access() supports DAXDEV_F_RECOVERY, so it may
translate a poisoned range. But if dm_dax_copy_to/from_iter()
don't have a dax_copy_to/from_iter() foundation underneath,
performing load/store over poisoned range is dangerous and
should be avoided.
Signed-off-by: Jane Chu
---
drivers
Let pmem_dax_direct_access() skip badblock checking if the caller
intends to do data recovery by providing the DAXDEV_F_RECOVERY flag.
Signed-off-by: Jane Chu
---
drivers/nvdimm/pmem.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm
Prepare dax_direct_access() API with DAXDEV_F_RECOVERY flag
such that the API may perform device address translation
in spite of the presence of poison(s) in a given range.
Signed-off-by: Jane Chu
---
drivers/dax/super.c | 9 +
drivers/md/dm-linear.c | 4 ++--
driv
Introduce RWF_RECOVERY_DATA flag to preadv2() and pwritev2()
for the purpose of recovering data loss due to dax media error.
Hence the functionality ties to the underlying media and driver
with capability to clear media error(s) on the fly.
When this flag is provided with preadv2(), preadv2() will
This patch set is a follow up to below conversation
https://lore.kernel.org/linux-xfs/20210927210750.gh1756...@dread.disaster.area/
where Dave Chinner proposed a single flag RWF_RECOVER_DATA to
be added to the system calls preadv2() and pwritev2() for the
purpose of user directed recovery from d
Wayne,
On Thu, 2021-09-30 at 14:32 +, berthiaume, wayne wrote:
> Hi Xose.
>
> OPM is no longer supported in the Dell VPLEX product. If we
> at Dell had wished to change the default device stanzas for any of
> our products they would have been done when the product and/or
> feature is
On Fri, 2021-10-08 at 20:24 +0800, chengjike wrote:
> After "Native NVME Multipath" is configured,
> the content displayed is incorrect when you run "multipath -ll"
> command.
> Each NVME devices have the same path name. For example:
>
> [root@localhost home]# multipath -ll
> eui.710032e8fb22a86c2
The path already must have a udev device at this point, so it just
needs to copy the sysname from it.
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs_vec.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libmultipath/structs_vec.c b/libmultipath/structs_vec.c
Avoiding this corner case simplifies a future patch
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs_vec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libmultipath/structs_vec.c b/libmultipath/structs_vec.c
index d363e7f6..fb26437a 100644
--- a/libmultipath/s
If a path device was removed from the system while multipathd was not
running, multipathd would not remove the path from the multipath table
on start-up, or on a weak reconfigure. update_pathvec_from_dm() would
return that a reload was necessary, but that information wasn't
propigated back to where
So, it turns out that commit 4ef67017 "libmultipath: add
update_pathvec_from_dm()" already does most of the hard work of making
multipath handle the uninitialized paths that exist during boot, after
the switch root, but before the all the coldplug uevents have been
processed. The only problem is th
multipathd can now handle starting up with incompletely initialized
paths, so it no longer needs to wait for the device Coldplug to
complete. However multipathd may need to write to /etc (for the wwids
and bindings files), so in needs to wait for the root filesystem to
be remounted read/write befor
The only reason multipath is monitoring an INIT_PARTIAL path is because
it was discovered in a multipath device table. If it stops being part
of a multipath device before it gets fully initialized, drop it.
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs_vec.c | 22 ++-
When paths are added by update_pathvec_from_dm(), udev may not have
initialized them. This means that it's possible that they are supposed
to be blacklisted by udev properties, but weren't. Also, in order to
avoid doing potentially stalling IO, update_pathvec_from_dm() doesn't
get all the path inf
When new paths are added in update_pathvec_from_dm(). If they can't get
their regular wwid, they shouldn't try the getting the fallback wwid,
and should just copy the wwid of the multipath device.
Signed-off-by: Benjamin Marzinski
---
libmultipath/discovery.c | 7 ---
libmultipath/discover
19 matches
Mail list logo
