Hello,
thank you all for your replies.
And of course good to hear that you are also open for this rather
special use case ;)
I will then revise the patch as you suggested, and send it again for review.
Frank
On 23.09.20 00:34, Martin Wilck wrote:
On Tue, 2020-09-22 at 17:27 -0500, Benjamin Marzinski wrote:
On Tue, Sep 22, 2020 at 09:59:36PM +0200, Martin Wilck wrote:
On Tue, 2020-09-22 at 20:34 +0200, Frank Meinl wrote:
This change adds a new configuration option allow_usb_devices. It
is
disabled by default, so that the behavior of existing setups is
not
changed. If enabled (via multipath.conf), USB devices will be
found
during device discovery and can be used for multipath setups.
Without this option, multipath currently ignores all USB drives,
which
is convenient for most users. (refer also to commit 51957eb)
However, it can be beneficial to use the multipath dm-module even
if
there is only a single path to an USB attached storage. In
combination
with the option 'queue_if_no_path', such a setup survives a
temporary
device disconnect without any severe consequences for the running
applications. All I/O is queued until the device reappears.
Hm. So you want to use multipath just to enable queueing?
I wonder if that can't be achieved some other way; multipath seems
to
be quite big hammer for this nail. Anyway, I don't think this would
hurt us, so I don't have good reasons to reject it.
Waiting for others' opinions.
I've actually seen other cases where people are using multipath on
single path devices just for the queuing, and when I thought about
it, I
realized that it makes sense. Multipath works with devices as they
are,
instead of needing special metadata, like lvm devices. People often
realize that they need this after the device is already set up. Plus,
multipath already deals with devices that have partitions or logical
volumes on top of them. It's also easy to configure exactly how you
want
queueing to work. This use case might be a small nail, but it is a
nail,
and multipath is a reasonable tool to get the job done.
It doesn't seem too hard to write a dm target that would queue and
retry
IO at some configurable interval, for some configurable number of
times,
when it failed. But you would also need to copy the work for getting
the
device, and any partitons on it, to autoassemble after the frist time
it's set up and to make sure other layers use this device instead of
the
underlying device. Or, people can just use multipath.
Ok. So Frank, please just clarify the remaining minor points. You may
actually want to put (a short version of) this motivation in the man
page.
Regards,
Martin
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
