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
