get_events() used a NULL or a zeroed timeout to mean "don't wait".
io_getevents() uses a NULL timeout to mean "wait forever" and a
zeroed timeout to mean "don't wait". Make get_events() work like
io_getevents().
Signed-off-by: Benjamin Marzinski
---
libmultipath/checkers/directio.c | 10 +---
The directio checker manually aligns its directio buffer, instead of
using posix_memalign(). It also defaults the block size for the read to
512, which may be too small for 4k devices, and it only waits for 5 ns
for IO completion before giving up and setting the path to pending,
which means that in
Signed-off-by: Benjamin Marzinski
---
kpartx/dasd.c| 6 +++---
libmultipath/print.c | 3 ++-
multipath/main.c | 2 +-
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/kpartx/dasd.c b/kpartx/dasd.c
index 1486ccaa..57305825 100644
--- a/kpartx/dasd.c
+++ b/kpartx/dasd.c
@@
Instead of always allocating space in the path structure for vpd_data,
only allocte it when necessary.
Also, fix comments on vpd tests
Signed-off-by: Benjamin Marzinski
---
libmultipath/discovery.c | 17 +++--
libmultipath/print.c | 4 ++--
libmultipath/structs.c | 3 +++
li
The directio checker previously made sure to always keep an aio_group
around after loading or resetting the checker. There is no need to do
this, and removing this code simplifies the checker. With this change,
there is no longer a need for a load or unload checker function, only a
reset function
These patches resolve various minor issues that Martin had with my
previous patch set.
Benjamin Marzinski (5):
multipath: fix issues found by compiling with gcc 10
libmultipath: turn pp->vpd_data into a pointer
libmultipath: change loading and resetting in directio
libmultipath: change dir
There is now a file in tests called directio_test_dev. If the commented
out test device line is uncommented and set to a device, it can be used
to test the directio checker on that device, instead of faking the
device.
Signed-off-by: Benjamin Marzinski
---
tests/Makefile | 16 +-
t
From: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/discovery.c | 2 +-
libmultipath/propsel.c | 2 +-
libmultipath/propsel.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libmultipath/discovery.c b/libmultipath/discovery.c
index 33a313a2..23a7889c
If the persistent in command fails, the response buffer must be freed.
Found by Coverity
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
mpathpersist/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mpathpersist/main.c b/mpathpersist/main.c
index 56761668..28bfe410 100
Right now, multipathd only ever calls pathinfo on a path outside of the
vecs lock in one circumstance, when it's adding a new path from a
uevent. Doing this can cause weirdness or crash multipathd.
First off, the path checker code is written assuming that only one
checker instance will be active a
This adds the wildcard 'g' for multipath and path formatted printing,
which returns extra data from a device's vendor specific vpd page. The
specific vendor vpd page to use, and the vendor/product id to decode it
can be set in the hwentry with vpd_vendor_pg and vpd_vendor_id. It can
be configured
On systems with a large number of cores (>500), io_destroy() can take
tens to hundreds of milliseconds to complete, due to RCU
synchronization. If there are a large number of paths using the directio
checker on such a system, this can lead to multipath taking almost a
minute to complete, with the v
If do_inq returns a page with a length that is less than maxlen, but
larger than DEFAULT_SGIO_LEN, this function will loop forever. Also
if do_inq returns with a length equal to or greater than maxlen,
sgio_get_vpd will exit immediately, even if it hasn't read the entire
page. Fix these issues, mo
Signed-off-by: Benjamin Marzinski
---
multipathd/uxlsnr.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/multipathd/uxlsnr.c b/multipathd/uxlsnr.c
index 020d7a9b..1c5ce9d2 100644
--- a/multipathd/uxlsnr.c
+++ b/multipathd/uxlsnr.c
@@ -40,7 +40,7 @@
#include "cli
This commit adds the optional functions libcheck_load, libcheck_unload,
and libcheck_reset. libcheck_load is called when a checker is first
loaded, libcheck_unload is called when it is unloaded, and
libcheck_reset is called during reconfigure, after all the current
paths have been removed. They are
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/unaligned.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libmultipath/unaligned.h b/libmultipath/unaligned.h
index 68c07742..b9eaa7cb 100644
--- a/libmultipath/unaligned.h
+++ b/libmultipath/u
The way that the checkers async mode worked in multipathd didn't make
much sense. When multipathd starts up, all checker classes are in the
sync mode, and any pathinfo() calls on devices would run the checker in
sync mode. However, the First time a checker class was used in
checkerloop, it would se
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/structs.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/libmultipath/structs.h b/libmultipath/structs.h
index c978fb8a..250623af 100644
--- a/libmultipath/structs.h
+++ b/libmultipath/structs.h
@@ -273,7 +273,6 @@
This tells multipath how it should decode vendor specific pages. It will
be used by a future patch.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/discovery.c | 4 ++--
libmultipath/discovery.h | 2 +-
libmultipath/propsel.c | 2 +-
tests/vpd.c |
It would be helpful if multipathd could log a message when
multipath.conf or files in the config_dir have been written to, both so
that it can be used to send a notification to users, and to help with
determining after the fact if multipathd was running with an older
config, when the logs of multip
This patch set is has multiple parts.
patch 01 is just a resubmit of my previous patch, with Martin's
corrections added.
Patches 02 - 06 are miscellaneous fixes and cleanups
Patches 07 - 09 are related to adding a new format wildcard, at the
request of HPE, that allows multipath to get a
multipath will try to get the priority from a PATH_DOWN path, if the
path doesn't currently have a valid priority. However, if the priority
code needs to contact the device to get the priority, this is likely to
fail for PATH_DOWN paths. This code dates back to when multipathd could
not easily rel
Signed-off-by: Benjamin Marzinski
---
tests/Makefile | 3 +-
tests/directio.c | 704 +++
2 files changed, 706 insertions(+), 1 deletion(-)
create mode 100644 tests/directio.c
diff --git a/tests/Makefile b/tests/Makefile
index c9406e75..e9081e8f 10
There were some variables in the hwe and mpe structs that weren't being
merged by merge_hwe() and merge_mpe().
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/config.c | 8
1 file changed, 8 insertions(+)
diff --git a/libmultipath/config.c b/libmultipath/c
From: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/checkers/directio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libmultipath/checkers/directio.c b/libmultipath/checkers/directio.c
index 740c68e5..813e61e2 100644
--- a/libmultipath/checkers/directio.
Hi,
This is V5 of patches. These patches are also available at.
https://github.com/rhvgoyal/linux/commits/dax-zero-range-v5
Changes since V4:
- Rebased on top of 5.6-rc2
- Added a separate patch so that pmem_clear_poison() accepts arbitrary
offset and len and aligns these as needed. This tak
This splits pmem_do_bvec() into pmem_do_read() and pmem_do_write().
pmem_do_write() will be used by pmem zero_page_range() as well. Hence
sharing the same code.
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Vivek Goyal
---
drivers/nvdimm/pmem.c | 86
This patch adds support for dax zero_page_range operation to dm targets.
Signed-off-by: Vivek Goyal
---
drivers/md/dm-linear.c| 21 +
drivers/md/dm-log-writes.c| 19 +++
drivers/md/dm-stripe.c| 26 ++
drivers/md/dm.c
Add a dax operation zero_page_range, to zero a range of memory. This will
also clear any poison in the range being zeroed.
As of now, zeroing of up to one page is allowed in a single call. There
are no callers which are trying to zero more than a page in a single call.
Once we grow the callers whi
Currently pmem_clear_poison() expects offset and len to be sector aligned.
Atleast that seems to be the assumption with which code has been written.
It is called only from pmem_do_bvec() which is called only from pmem_rw_page()
and pmem_make_request() which will only passe sector aligned offset and
Get rid of calling block device interface for zeroing in iomap dax
zeroing path and use dax native zeroing interface instead.
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Vivek Goyal
---
fs/dax.c | 45 +
1 file change
Add a helper dax_ioamp_zero() to zero a range. This patch basically
merges __dax_zero_page_range() and iomap_dax_zero().
Suggested-by: Christoph Hellwig
Reviewed-by: Christoph Hellwig
Signed-off-by: Vivek Goyal
---
fs/dax.c | 12 ++--
fs/iomap/buffered-io.c | 9 +
Add dax operation zero_page_range for dcssblk driver.
CC: linux-s...@vger.kernel.org
Suggested-by: Christoph Hellwig
Reviewed-by: Gerald Schaefer
Signed-off-by: Vivek Goyal
---
drivers/s390/block/dcssblk.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/s390/bloc
Currently pmem_do_write() is written with assumption that all I/O is
sector aligned. Soon I want to use this function in zero_page_range()
where range passed in does not have to be sector aligned.
Modify this function to be able to deal with an arbitrary range. Which
is specified by pmem_off and l
On Tue, Feb 18, 2020 at 09:09:28AM -0800, Christoph Hellwig wrote:
> On Mon, Feb 17, 2020 at 01:16:48PM -0500, Vivek Goyal wrote:
> > Currently pmem_do_write() is written with assumption that all I/O is
> > sector aligned. Soon I want to use this function in zero_page_range()
> > where range passed
On Mon, Feb 17, 2020 at 01:16:47PM -0500, Vivek Goyal wrote:
> This splits pmem_do_bvec() into pmem_do_read() and pmem_do_write().
> pmem_do_write() will be used by pmem zero_page_range() as well. Hence
> sharing the same code.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Vivek Goyal
Lo
> +static int pmem_dax_zero_page_range(struct dax_device *dax_dev, u64 offset,
> + size_t len)
> +{
> + struct pmem_device *pmem = dax_get_private(dax_dev);
> + blk_status_t rc;
> +
> + rc = pmem_do_write(pmem, ZERO_PAGE(0), 0, offset, len);
> + retur
On Mon, Feb 17, 2020 at 01:16:48PM -0500, Vivek Goyal wrote:
> Currently pmem_do_write() is written with assumption that all I/O is
> sector aligned. Soon I want to use this function in zero_page_range()
> where range passed in does not have to be sector aligned.
>
> Modify this function to be abl
38 matches
Mail list logo