Re: [PATCH 4/5] kpartx: default to running in sync mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx>, 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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux