If kpartx is used on top of shared storage, and a device has its
partition table changed on one machine, and then kpartx is run on
another, it may not see the new data, because the cache still contains
the old data, and there is nothing to tell the machine running kpartx to
invalidate it. To solve
This is a small collection of individual bug fix patches that apply on
top of my previous patch set.
Changes from v1:
0001: Going with Martin's strtoul() method instead
0002: Now getpagesize() is only called once, and size_p is only set if
posix_memalign is successful, as suggested
bsd disk labels can either be at the start of the second sector, or 64
bytes into the first sector, but kpartx only handled the first case.
However the second case is what parted creates, and what the linux
kernel partition code expects. kpartx should handle both cases.
Reviewed-by: Martin Wilck
dev_loss_tmo is a u32 value. However the kernel sysfs code prints it as
a signed integer. This means that if dev_loss_tmo is above INT_MAX, the
sysfs value will be a negative number. Parsing this was causing
sysfs_set_rport_tmo() to fail.
Signed-off-by: Benjamin Marzinski
Signed-off-by: Martin
In order to fix hwhandler autodetection, commit 8794a776 made
detect_alua() differentiate between failures to detect whether alua was
supported, and successfully detecting that it was not supported.
However, this causes nvme devices to get the TUR checker assigned to
them. This is because there is
Add the -D option to allow users to skip delegating commands to
multipathd.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/config.h | 1 +
multipath/main.c | 8 +++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libmultipath/config.h
dm_flush_maps() returned both 0 and 1 on error, depending on which part
of the function it was in, but the caller was always treating 0 as a
success. Make dm_flush_maps() always return 1 on error and 0 on success.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
This will flush all multipath devices.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/devmapper.c | 7 +--
libmultipath/devmapper.h | 2 +-
multipath/main.c | 2 +-
multipathd/cli.c | 1 +
multipathd/cli_handlers.c | 19
If a multipath device is removed during, or immediately before the call
to check_path(), multipathd can behave incorrectly. A missing multpath
device will cause update_multipath_strings() to fail, setting
pp->dmstate to PSTATE_UNDEF. If the path is up, this state will cause
reinstate_path() to be
The config structure doesn't need a special variable just for removes.
Multipath can just use the cmd variable, like it does for the other
commands.
Reviewed-by: Martin Wilck
Signed-off-by: Benjamin Marzinski
---
libmultipath/config.h| 3 ++-
libmultipath/configure.h | 3 ---
dm_get_map() and dm_get_status() now use symbolic return codes. They
also differentiate between failing to get information from device-mapper
and not finding the requested device. These symboilc return codes are
also used by update_multipath_* functions.
Signed-off-by: Benjamin Marzinski
---
Since there can be problems with removing maps outside of multipathd,
multipath should attempt to delegate this command to multipathd.
However, multipathd doesn't attempt to suspend the device, in order
to avoid potential hangs. If delegating to multipathd fails, multipath
should try the remove
If a multipath device is removed, and check_path() checks one of its
paths before multipathd processes either the uevent or the dm event from
removing it, multipathd will recreate the removed device. This happens
because check_path() will continute to check the removed device's former
paths until
On Thu, Jul 02, 2020 at 11:52:21AM +, Martin Wilck wrote:
> On Wed, 2020-03-25 at 17:00 -0500, Benjamin Marzinski wrote:
> > On Wed, Mar 25, 2020 at 03:52:55PM -0500, Benjamin Marzinski wrote:
> > > On Wed, Mar 25, 2020 at 03:16:50PM +, Martin Wilck wrote:
> > > > On Tue, 2020-03-24 at
On Thu, Jul 02, 2020 at 04:45:21PM +, Martin Wilck wrote:
> On Thu, 2020-07-02 at 10:18 -0500, Benjamin Marzinski wrote:
> > On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> > > On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > > > On Wed, Jul 01, 2020 at
On Wed, Jul 01, 2020 at 08:19:57PM +, Martin Wilck wrote:
> On Thu, 2020-06-25 at 15:42 -0500, Benjamin Marzinski wrote:
> > If a multipath device is removed during, or immediately before the
> > call
> > to check_path(), multipathd can behave incorrectly. A missing
> > multpath
> > device
On Wed, Jul 01, 2020 at 08:15:49PM +, Martin Wilck wrote:
> On Thu, 2020-06-25 at 15:42 -0500, Benjamin Marzinski wrote:
> > dm_get_map() and dm_get_status() now use symbolic return codes. They
> > also differentiate between failing to get information from device-
> > mapper
> > and not
On Thu, 2020-07-02 at 10:18 -0500, Benjamin Marzinski wrote:
> On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> > On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > > On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > > > On Thu, 2020-06-18 at 18:06
On Thu, Jul 02, 2020 at 03:00:37PM +, Martin Wilck wrote:
> On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> > If kpartx is used on top of shared storage, and a device has its
> > partition table changed on one machine, and then kpartx is run on
> > another, it may not see the
On Thu, Jul 02, 2020 at 02:31:17PM +, Martin Wilck wrote:
> On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> > dev_loss_tmo is a u32 value. However the kernel sysfs code prints it
> > as
> > a signed integer. This means that if dev_loss_tmo is above INT_MAX,
> > the
> > sysfs
On Thu, Jul 02, 2020 at 03:12:58PM +, Martin Wilck wrote:
> On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> > bsd disk labels can either be at the start of the second sector, or
> > 64
> > bytes into the first sector, but kpartx only handled the first case.
> > However the
On Thu, Jul 02, 2020 at 12:24:32PM +, Martin Wilck wrote:
> On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> > On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > > On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> > > > I uploaded the test program,
On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> In order to fix hwhandler autodetection, commit 8794a776 made
> detect_alua() differentiate between failures to detect whether alua
> was
> supported, and successfully detecting that it was not supported.
> However, this causes nvme
On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> bsd disk labels can either be at the start of the second sector, or
> 64
> bytes into the first sector, but kpartx only handled the first case.
> However the second case is what parted creates, and what the linux
> kernel partition
On Thu, Jul 02, 2020 at 10:10:10AM -0400, Qian Cai wrote:
> On Mon, Jun 29, 2020 at 09:39:45PM +0200, Christoph Hellwig wrote:
> > Split out a __submit_bio_noacct helper for the actual de-recursion
> > algorithm, and simplify the loop by using a continue when we can't
> > enter the queue for a
On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> If kpartx is used on top of shared storage, and a device has its
> partition table changed on one machine, and then kpartx is run on
> another, it may not see the new data, because the cache still
> contains
> the old data, and there
On 2020/7/1 16:59, Christoph Hellwig wrote:
> generic_make_request has always been very confusingly misnamed, so rename
> it to submit_bio_noacct to make it clear that it is submit_bio minus
> accounting and a few checks.
>
> Signed-off-by: Christoph Hellwig
I will miss generic_make_request().
On 2020/7/1 16:59, Christoph Hellwig wrote:
> The make_request_fn is a little weird in that it sits directly in
> struct request_queue instead of an operation vector. Replace it with
> a block_device_operations method called submit_bio (which describes much
> better what it does). Also remove
On 2020/7/1 16:59, Christoph Hellwig wrote:
> Nothing in bcache actually uses the ->queuedata field.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Coly Li
> ---
> drivers/md/bcache/super.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/md/bcache/super.c
On Wed, 2020-07-01 at 17:39 -0500, Benjamin Marzinski wrote:
> dev_loss_tmo is a u32 value. However the kernel sysfs code prints it
> as
> a signed integer. This means that if dev_loss_tmo is above INT_MAX,
> the
> sysfs value will be a negative number. Parsing this was causing
>
On Wed, 2020-07-01 at 22:14 -0500, Benjamin Marzinski wrote:
> On Wed, Jul 01, 2020 at 10:54:34PM +0200, Martin Wilck wrote:
> > On Thu, 2020-06-18 at 18:06 -0500, Benjamin Marzinski wrote:
> > > I uploaded the test program, aio_test:
> > >
> > > https://github.com/bmarzins/test_programs.git
> >
On Wed, 2020-03-25 at 17:00 -0500, Benjamin Marzinski wrote:
> On Wed, Mar 25, 2020 at 03:52:55PM -0500, Benjamin Marzinski wrote:
> > On Wed, Mar 25, 2020 at 03:16:50PM +, Martin Wilck wrote:
> > > On Tue, 2020-03-24 at 16:03 -0500, Benjamin Marzinski wrote:
> > >
> > > AFAICS, this function
On Wed, Jul 1, 2020 at 2:06 AM Christoph Hellwig wrote:
>
> Except for pktdvd, the only places setting congested bits are file
> systems that allocate their own backing_dev_info structures. And
> pktdvd is a deprecated driver that isn't useful in stack setup
> either. So remove the dead
On Wed, Jul 1, 2020 at 2:02 AM Christoph Hellwig wrote:
>
> The queue can be trivially derived from the bio, so pass one less
> argument.
>
> Signed-off-by: Christoph Hellwig
> ---
[...]
> drivers/md/md.c | 2 +-
For md.c:
Acked-by: Song Liu
--
dm-devel mailing list
34 matches
Mail list logo
