From: Benjamin Marzinski <bmarzins@redhat.com>
To: Martin Wilck <martin.wilck@suse.com>
Cc: Christophe Varoqui <christophe.varoqui@opensvc.com>,
device-mapper development <dm-devel@lists.linux.dev>
Subject: Re: [PATCH v2 2/5] libmultipath: change flush_on_last_del to fix a multipathd hang
Date: Tue, 30 Apr 2024 17:29:19 -0400 [thread overview]
Message-ID: <ZjFir8_To8UGoYVK@redhat.com> (raw)
In-Reply-To: <5a5aa59a1b60ee0e91abeec292ef3d591d55a7e7.camel@suse.com>
On Tue, Apr 30, 2024 at 07:06:24PM +0200, Martin Wilck wrote:
> On Thu, 2024-04-25 at 19:35 -0400, Benjamin Marzinski wrote:
> >
> > 1. create a multipath device with a kpartx partition on top of it and
> > no_path_retry set to either "queue" or something long enough to run
> > all
> > the commands in the reproducer before it disables queueing.
> > 2. disable all the paths to the device with something like:
> > # echo offline > /sys/block/<path_dev>/device/state
> > 3. Write directly to the multipath device with something like:
> > # dd if=/dev/zero of=/dev/mapper/<mpath_dev> bs=4K count=1
> > 4. delete all the paths to the device with something like:
> > # echo 1 > /sys/block/<path_dev>/device/delete
>
> I've tried to reproduce the issue with these commands. Test system was
> using a LIO iSCSI target with 2 paths. I created a test script
> (attached) to try the offline / IO / delete procedure repeatedly.
> I haven't been able to make multipathd hang even once.
>
> I also played around with dd options. If I use oflag=sync or
> oflag=direct, the dd command itself hangs.
>
> Did I set up anything wrongly, or does the behavior perhaps depend on
> the kernel, or something else perhaps? Mine was a 6.4 kernel. This is
> not to say there's something wrong with your patch, but I'd like to
> understand the error situation better, as it doesn't seem to be
> trigger-able on my test system.
>
> multipath.conf:
>
> defaults {
> verbosity 3
> flush_on_last_del yes
If you set flush_on_last_del to "yes", then you won't be able to hit
this, because you will never be queueing when multipathd tries to
autoremove the device. The goal of my patch was to make sure multipathd
never hung on an autoremove, regardless of the no_path_retry setting and
the flush_on_last_del setting.
With "always", the device will always have queueing disabled, so the
device can be safely removed.
With "unused", if the device is unused, queuing is disabled. Otherwise,
multipathd will skip the autoremove if the device is queueing.
With "never", multipathd will skip the autoremove if the device is
queueing.
Your script looks fine, but with a system set up to hit it, the bug
should occur every time.
-Ben
> }
>
> blacklist {
> wwid QEMU
> }
>
> overrides {
> no_path_retry queue
> }
>
> Regards,
> Martin
>
>
>
next prev parent reply other threads:[~2024-04-30 21:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-25 23:35 [PATCH v2 0/5] multipath: fix hang in flush_map_nopaths Benjamin Marzinski
2024-04-25 23:35 ` [PATCH v2 1/5] libmultipath: export partmap_in_use Benjamin Marzinski
2024-04-25 23:35 ` [PATCH v2 2/5] libmultipath: change flush_on_last_del to fix a multipathd hang Benjamin Marzinski
2024-04-30 17:06 ` Martin Wilck
2024-04-30 21:29 ` Benjamin Marzinski [this message]
2024-05-02 8:36 ` Martin Wilck
2024-05-02 15:06 ` Martin Wilck
2024-04-25 23:35 ` [PATCH v2 3/5] libmultipath: remove redundant config option from InfiniBox config Benjamin Marzinski
2024-04-25 23:35 ` [PATCH v2 4/5] libmultipath: pad dev_loss_tmo to avoid race with no_path_retry Benjamin Marzinski
2024-05-02 15:14 ` Martin Wilck
2024-05-02 16:05 ` Benjamin Marzinski
2024-05-02 18:44 ` Martin Wilck
2024-04-25 23:35 ` [PATCH v2 5/5] libmultipath: fix deferred_remove function arguments Benjamin Marzinski
2024-05-02 15:52 ` Martin Wilck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZjFir8_To8UGoYVK@redhat.com \
--to=bmarzins@redhat.com \
--cc=christophe.varoqui@opensvc.com \
--cc=dm-devel@lists.linux.dev \
--cc=martin.wilck@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.