On Fri, Nov 05, 2021 at 07:16:38PM -0600, Jane Chu wrote:
> For /dev/pmem based dax, enable DAX_OP_RECOVERY mode for
> dax_direct_access to translate 'kaddr' over a range that
> may contain poison(s); and enable dax_copy_to_iter to
> read as much data as possible up till a poisoned page is
>
On Fri, Nov 05, 2021 at 07:16:37PM -0600, Jane Chu wrote:
> Introduce DAX_OP_NORMAL and DAX_OP_RECOVERY operation modes to
> {dax_direct_access, dax_copy_from_iter, dax_copy_to_iter}.
> DAX_OP_NORMAL is the default or the existing mode, and
> DAX_OP_RECOVERY is a new mode for data recovery
Introduce DAX_OP_NORMAL and DAX_OP_RECOVERY operation modes to
{dax_direct_access, dax_copy_from_iter, dax_copy_to_iter}.
DAX_OP_NORMAL is the default or the existing mode, and
DAX_OP_RECOVERY is a new mode for data recovery purpose.
When dax-FS suspects dax media error might be encountered
on a
For /dev/pmem based dax, enable DAX_OP_RECOVERY mode for
dax_direct_access to translate 'kaddr' over a range that
may contain poison(s); and enable dax_copy_to_iter to
read as much data as possible up till a poisoned page is
encountered; and enable dax_copy_from_iter to clear poison
among a
Up till now, the method commonly used for data recovery from
dax media error has been a combination of hole-punch followed
by a pwrite(2). The downside of this method is that it causes
fragmentation of the pmem backend, which brings a host of
very challenging issues.
This patch is an attempt to
On Fri, Nov 05, 2021 at 12:03:12PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
Reviewed-by: Benjamin Marzinski
>
> Enable printing pp->initialized with 'multipathd show paths format "%I"'.
> This is supposed to go on top of Ben's "multipathd: remove udev settle
> dependency" series, to
On Fri, Nov 05, 2021 at 12:01:27PM +0100, mwi...@suse.com wrote:
> From: Martin Wilck
>
> We must set the return value in configure().
Reviewed-by: Benjamin Marzinski
> ---
> multipath/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/multipath/main.c b/multipath/main.c
> index
On Fri, Nov 05, 2021 at 10:55:11AM +, Martin Wilck wrote:
> Hi Ben,
>
> On Thu, 2021-11-04 at 23:10 +0100, Martin Wilck wrote:
> > On Wed, 2021-10-20 at 14:15 -0500, Benjamin Marzinski wrote:
> > > ...
> >
> > >
> > > Multipath now has a new state to deal with these devices,
> > >
On Thu, Nov 04, 2021 at 10:10:18PM +, Martin Wilck wrote:
> On Wed, 2021-10-20 at 14:15 -0500, Benjamin Marzinski wrote:
> > 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
On Thu, Nov 04, 2021 at 10:00:11PM +, Martin Wilck wrote:
> On Wed, 2021-10-20 at 14:15 -0500, Benjamin Marzinski wrote:
> > 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
On Thu, Nov 04, 2021 at 09:11:34PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > Add error reporting to the remaining config handlers. If the value is
> > invalid, do not change the existing config option's value.
>
> Like for the previous patch,
On Thu, Nov 04, 2021 at 08:54:11PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > Split the code that does the actual value parsing out of set_int(),
> > into
> > a helper function, do_set_int(), so that it can be used by other
> > handlers. These
On Fri, Nov 05, 2021 at 06:59:11AM +, Martin Wilck wrote:
> Hi Ben,
>
> On Thu, 2021-11-04 at 21:34 +0100, Martin Wilck wrote:
> > On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > > multipath always requires absolute pathnames, so make sure all file
> > > and
> > > directory
On Thu, Nov 04, 2021 at 08:34:20PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > multipath always requires absolute pathnames, so make sure all file
> > and
> > directory names start with a slash. Also check that the directories
> > exist. Finally,
On Thu, Nov 04, 2021 at 08:34:33PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > If a value outside of the valid range is passed to set_int, it caps
> > the
> > value at appropriate limit, and issues a warning.
> >
> > Signed-off-by: Benjamin
On Thu, Nov 04, 2021 at 08:55:39PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > If users forget the closing brace for a section in multipath.conf,
> > multipath has no way to detect that. When it sees the keyword at the
> > start of the next
On Thu, Nov 04, 2021 at 08:55:02PM +, Martin Wilck wrote:
> On Wed, 2021-10-06 at 15:04 -0500, Benjamin Marzinski wrote:
> > This will make it possible for the keyword handlers to print more
> > useful
> > warning messages. It will be used by future patches.
> >
> > Signed-off-by: Benjamin
On 04.11.2021 15:37, Keith Busch wrote:
On Thu, Nov 04, 2021 at 06:34:31PM +0100, Christoph Hellwig wrote:
On Thu, Nov 04, 2021 at 10:32:35AM -0700, Darrick J. Wong wrote:
> I also wonder if it would be useful (since we're already having a
> discussion elsewhere about data integrity syscalls
On Thu, Nov 04, 2021 at 06:34:31PM +0100, Christoph Hellwig wrote:
> On Thu, Nov 04, 2021 at 10:32:35AM -0700, Darrick J. Wong wrote:
> > I also wonder if it would be useful (since we're already having a
> > discussion elsewhere about data integrity syscalls for pmem) to be able
> > to call this
On Wed, Nov 03, 2021 at 11:46:29PM -0700, Chaitanya Kulkarni wrote:
> +static inline blk_status_t nvme_setup_verify(struct nvme_ns *ns,
> + struct request *req, struct nvme_command *cmnd)
> +{
Due to recent driver changes, you need a "memset(cmnd, 0, sizeof(*cmnd))"
prior to setting
20 matches
Mail list logo
