Linux Device Mapper development
 help / color / mirror / Atom feed
From: Martin Wilck <mwilck@suse.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
Cc: dm-devel@redhat.com
Subject: Re: [PATCH 4/5] kpartx: default to running in sync mode
Date: Thu, 11 May 2017 22:01:33 +0200	[thread overview]
Message-ID: <1494532893.6093.32.camel@suse.com> (raw)
In-Reply-To: <20170511174635.GI22856@octiron.msp.redhat.com>

On Thu, 2017-05-11 at 12:46 -0500, Benjamin Marzinski wrote:
> On Thu, May 11, 2017 at 02:42:08PM +0200, Martin Wilck wrote:
> > Hi Ben,
> > 
> > On Mon, 2017-04-24 at 17:39 -0500, Benjamin Marzinski wrote:
> > 
> > > When users run kpartx, they would naturally assume that when it
> > > completes, the devices have been created. However, kpartx runs in
> > > async
> > > mode by default.  This seems like it is likely to trip up users. 
> > 
> > Is this just likely, or do you have evidence that it really did
> > irritate users? You introduced "sync mode", together with the "-s"
> > flag, yourself in 2010, and unless I'm mistaken, kpartx operated in
> > "async" mode before that, too, because there was no "sync" mode. 
> 
> Yes. I made this patch after the second time a customer complained
> that
> kpartx wasn't working correctly, when the real issue was that their
> scripts were assuming that after the kpartx command completed, those
> partition device nodes would be present. Obviously, 2 isn't a huge
> number, but it certainly has caused confusion in some cases.

2 > "likely", that makes a difference.

> > I'm not too fond of the idea to change a default which has been
> > established for such a long time just because user mistakes are
> > "likely". For one thing, such changes are difficult to document in
> > a
> > way that doesn't cause confusion. Also, if someone writes a script
> > in
> > which she wants kpartx to run asynchronously, it will be difficult
> > to
> > do so in a manner which is portable between distributions if some
> > distributions include this patch and some don't.
> 
> I see your point, but assuming that I am correct that most users do
> assume that kpartx runs synchronously, I feel like we shouldn't keep
> a
> bad default forever, simply because it's always been that way. lvm
> and
> dmsetup wait for udev by default (well, on lvm IIRC it is a compile-
> time
> setting, but here is some SUSE documentation showing that it uses
> udev
> synchronization by default
> https://www.suse.com/documentation/sles-12/stor_admin/data/sec_lvm_cl
> i.html)
> kpartx does seem to be the odd one out.
> 
> > As an alternative, we might simply warn about the default
> > asynchronous
> > behavior in a prominent place in the man page.
> 
> We could, and if you are opposed to this patch, that would probably
> help
> cut down any confusion (assuming that when customers see things go
> wrong
> they read the documentation before calling support).

I still don't like it too much. The scripting issue is my biggest
concern - users need at least a reliable way to test whether or not 
"-n" is supported by kpartx on a given system.

But I, alone, am not in a position to veto this.

Does anyone else have an opinion on this change?

Martin

-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

  reply	other threads:[~2017-05-11 20:01 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-24 22:39 [PATCH 0/5] More misc patches Benjamin Marzinski
2017-04-24 22:39 ` [PATCH 1/5] multipath: Merge the DELL MD3xxx device configs Benjamin Marzinski
2017-04-24 22:39 ` [PATCH 2/5] multipath: fix up position independent code Benjamin Marzinski
2017-05-11 13:12   ` Martin Wilck
2017-04-24 22:39 ` [PATCH 3/5] libmultipath: fix partition detection Benjamin Marzinski
2017-05-11 13:07   ` Martin Wilck
2017-04-24 22:39 ` [PATCH 4/5] kpartx: default to running in sync mode Benjamin Marzinski
2017-04-25 10:12   ` Steffen Maier
2017-04-25 15:52     ` Benjamin Marzinski
2017-04-25 17:48       ` Steffen Maier
2017-05-10 22:42   ` Xose Vazquez Perez
2017-05-11 12:42   ` Martin Wilck
2017-05-11 17:46     ` Benjamin Marzinski
2017-05-11 20:01       ` Martin Wilck [this message]
2017-04-24 22:39 ` [PATCH 5/5] libmultipath: force udev reloads Benjamin Marzinski

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=1494532893.6093.32.camel@suse.com \
    --to=mwilck@suse.com \
    --cc=bmarzins@redhat.com \
    --cc=dm-devel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox