Loïc Minier wrote: > On Thu, Dec 07, 2006, Sjoerd Simons wrote: >> In this case i'd say it's something lilo should work around by preferring >> /dev/mapper/* devices. > > That's the workaround I proposed as well, but I'm not using lilo > anywhere and don't feel like I'm empowered to do some lilo hacking. I > also suggested to check why ioctls that work no the same major/minor > fail against /dev/dm-* but succeed against /dev/mapper/*, as I think > making these succeed would also solve the bug. >
Attached is a log of a discussion I had with davidz and kay on irc. Maybe that helps to understand this problem better. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
[Fr Okt 27 2006] [01:15:36] <mbiebl> kay: hi [Fr Okt 27 2006] [01:15:53] <kay> mbiebl: hi [Fr Okt 27 2006] [01:16:05] <mbiebl> davidz and I discussed yesterday if it is correct to keep the /dev/dm-* devices. [Fr Okt 27 2006] [01:16:21] <krh> so what is libusual anyway? [Fr Okt 27 2006] [01:16:23] <kay> davidz: he should merge libususl with nash :) [Fr Okt 27 2006] [01:16:25] <mbiebl> Debian currently has a rule to suppress the creation of these devices. [Fr Okt 27 2006] [01:16:52] <kay> krh: a kernel solution to pick a driver for a device when they are competing, ugh ... [Fr Okt 27 2006] [01:16:59] <davidz> krh: it's uhm.. some weirdo hack so ub and usb-storage can share usb device quirks or something [Fr Okt 27 2006] [01:17:14] <krh> gah [Fr Okt 27 2006] [01:17:20] * davidz have no idea how pete got that past Linus [Fr Okt 27 2006] [01:17:28] <krh> it's upstream? [Fr Okt 27 2006] [01:17:32] <davidz> oh yeah [Fr Okt 27 2006] [01:17:43] <kay> mbiebl: well, it depends, there is no general rule [Fr Okt 27 2006] [01:17:44] <davidz> Linux got two (at least) usb storage device drivers [Fr Okt 27 2006] [01:17:44] <mbiebl> kay: I heard different opionions so far. [Fr Okt 27 2006] [01:17:50] <krh> I don't see how my stack can possibly be rejected then [Fr Okt 27 2006] [01:17:58] <davidz> krh: heh, yup :-) [Fr Okt 27 2006] [01:18:07] <mbiebl> Some fellow DDs told me, that /dev/mapper/* is the canonical way nowadays. [Fr Okt 27 2006] [01:18:09] <krh> what's another stack? [Fr Okt 27 2006] [01:18:16] <krh> after all, it's all about choice! [Fr Okt 27 2006] [01:19:01] <kay> mbiebl: it's that way from the beginning, yes. but dm is just broken regarding hotplug, so there is no rule out there [Fr Okt 27 2006] [01:19:01] * krh ducks [Fr Okt 27 2006] [01:19:04] <mbiebl> Yet udev reports /dev/dm-* upon creation of dm devices. [Fr Okt 27 2006] [01:19:20] <kay> mbiebl: sure, that's what the kernel announces [Fr Okt 27 2006] [01:19:44] <davidz> mbiebl: long term it's not a very good idea to have > 1 programs writing in /dev ... it will take some time to get all this fixed though [Fr Okt 27 2006] [01:20:00] <kay> mbiebl: that the dm tools maintain their own nodes is just a bug of the lazy hackers ... :) [Fr Okt 27 2006] [01:21:04] <mbiebl> It would be good, to have a clear guideline what is supposed to be the right way (tm) and what not. [Fr Okt 27 2006] [01:21:35] <kay> mbiebl: the right way is to fix dm in its general operation, not the name of the nodes :) [Fr Okt 27 2006] [01:22:12] <mbiebl> Ok, so you also agree to keep the /dev/dm-* device nodes? [Fr Okt 27 2006] [01:22:12] <kay> mbiebl: it can't ignore hotplug these days, but it isn't designed with that in mind [Fr Okt 27 2006] [01:22:59] <kay> mbiebl: i keep them on SUSE, because I don't care if there are additional nodes [Fr Okt 27 2006] [01:23:01] <mbiebl> I'm not so much into the device mapper stuff, I only hear different opinions. [Fr Okt 27 2006] [01:23:47] <kay> mbiebl: but there is no rule, dm needs to intergrate with the hotplug world, until that's done there will be different ways to work around it ... [Fr Okt 27 2006] [01:23:50] <mbiebl> The d-m people tell me, that hal/g-m should be *fixed* to use /dev/mapper, and davidz tells me that /dev/dm* is the way to go. [Fr Okt 27 2006] [01:24:21] <kay> mbiebl: i would peraonally call /dev/mapper a silly bug :) [Fr Okt 27 2006] [01:24:28] <mbiebl> hehe [Fr Okt 27 2006] [01:24:45] <davidz> mbiebl: well... the dm people agree that fixing dm is the right approach [Fr Okt 27 2006] [01:25:03] <kay> mbiebl: it's a disk/blockdev, not a mapper :) [Fr Okt 27 2006] [01:25:23] <kay> mbiebl: and we should use /dev/disk/by-*/ for every blockdev [Fr Okt 27 2006] [01:25:40] <kay> mbiebl: calling dm tools to mess around in /dev is just crazy ... [Fr Okt 27 2006] [01:26:00] <davidz> so... basically agk (dm maintainer) says this [Fr Okt 27 2006] [01:26:02] <davidz> udev needs to completely ignore the 'add' event, and instead act on the 'change' [Fr Okt 27 2006] [01:26:02] <davidz> event. Until the change event arrives under no circumstances should udev [Fr Okt 27 2006] [01:26:02] <davidz> attempt to open the dm device or query any dm device properties. In future lvm2 [Fr Okt 27 2006] [01:26:02] <davidz> and other applications will then wait until udev has completed processing the [Fr Okt 27 2006] [01:26:02] <davidz> 'change' event before proceeding. udev will then be able to assume full [Fr Okt 27 2006] [01:26:03] <davidz> responsibility for /dev/mapper - the 'change' event will cause the nodes to be [Fr Okt 27 2006] [01:26:07] <davidz> added to /dev. There is no way to do this correctly in response to the existing [Fr Okt 27 2006] [01:26:09] <davidz> 'add' event, because the dm properties udev needs to query are not yet defined [Fr Okt 27 2006] [01:26:11] <davidz> in-kernel at this point. The 'change' event is the new signal that the [Fr Okt 27 2006] [01:26:13] <davidz> properties are now fully defined. [Fr Okt 27 2006] [01:26:15] <davidz> ... [Fr Okt 27 2006] [01:26:17] <davidz> and [Fr Okt 27 2006] [01:26:19] <davidz> Further, whenever the in-kernel device configuration changes significantly, a [Fr Okt 27 2006] [01:26:21] <davidz> new 'change' event will be issued, and udev will need to check the device [Fr Okt 27 2006] [01:26:23] <davidz> properties and may need to modify the corresponding /dev entries at that point. [Fr Okt 27 2006] [01:26:25] <davidz> ... [Fr Okt 27 2006] [01:26:57] <kay> davidz: well, "add" can create the node, there is no problem with it [Fr Okt 27 2006] [01:27:27] <kay> davidz: only for today's hal, it may be an easy way to let hal fail on that event :) [Fr Okt 27 2006] [01:27:28] <mbiebl> kay: I don't have that much experiences in that regard (yet), I only see that hal with respect to luks is currently broken in Debian. [Fr Okt 27 2006] [01:27:29] <davidz> mbiebl, kay: so I do think medium-term we need to help distros here.... e.g. tell them to include http://lkml.org/lkml/2006/9/15/310 ... and what udev rules to use? [Fr Okt 27 2006] [01:27:54] <davidz> kay: so... perhaps sending a mail to the hal list about this would be useful? [Fr Okt 27 2006] [01:27:54] <mbiebl> And I'm looking for advise what the correct solution is. [Fr Okt 27 2006] [01:28:00] <davidz> then we can point people in that direction [Fr Okt 27 2006] [01:28:34] <davidz> kay: basically... I would make udev ignore 'add'... and only send an event to hal on 'change'.... how about that? [Fr Okt 27 2006] [01:28:41] <kay> the "change" is upstream, what do you mean with include? for older kernels? [Fr Okt 27 2006] [01:28:46] <davidz> yeah [Fr Okt 27 2006] [01:28:59] <kay> davidz: that does not work on coldplug, there will be no change event [Fr Okt 27 2006] [01:29:00] <mbiebl> upstream means .19? [Fr Okt 27 2006] [01:29:19] <davidz> kay: you know... if only udev shipped with predefined... rules... then this would be much easier :-) [Fr Okt 27 2006] [01:29:21] * davidz trolls [Fr Okt 27 2006] [01:29:27] <davidz> kay: right.. ok.. ugh.. coldplug... god point [Fr Okt 27 2006] [01:29:34] <davidz> good point even [Fr Okt 27 2006] [01:30:17] <kay> davidz: hehe, we should get a common initramfs too :) [Fr Okt 27 2006] [01:31:03] <kay> mbiebl: v2.6.19-rc1, yeah [Fr Okt 27 2006] [01:32:45] <kay> davidz: there is still the unresolved prob with snapshots, everybody needs to ignore them, but the dm tools can't get that info from the dev [Fr Okt 27 2006] [01:33:11] <kay> davidz: that's why the dm guys want to ignore everything [Fr Okt 27 2006] [01:34:18] <kay> davidz: but they seem to forget, that we want uuid/label links and we hotplug stuff and have more thatn fstab :) [Fr Okt 27 2006] [01:34:27] <davidz> kay: yeah [Fr Okt 27 2006] [01:35:17] <kay> davidz, mbiebl: so there is no real solution today, whatever you do, option you choose, something will break/not work [Fr Okt 27 2006] [01:36:21] <kay> davidz, mbiebl: snapshots or luks/persistent links, only one of them works with the current tools [Fr Okt 27 2006] [01:39:28] <davidz> kay: have anyone figured out what we need to fix? [Fr Okt 27 2006] [01:39:34] <kay> davidz: but we have a customer bug open, that needs to be solved, so someone is working on it already, we'll see ... [Fr Okt 27 2006] [01:39:59] <kay> davidz: the last idea was to use the "tagging" functionality of dm to tag stuff as private or whatever ... [Fr Okt 27 2006] [01:40:38] <kay> davidz: i can ask tomorrow, what's the current idea ... [Fr Okt 27 2006] [01:41:47] <davidz> kay: that would be appreciated, thanks [Fr Okt 27 2006] [01:41:57] <davidz> I need to fix it too for Fedora [Fr Okt 27 2006] [01:42:11] <davidz> and probably face the same kind of ppl as mbiebl is facing in the Debian community [Fr Okt 27 2006] [01:43:08] <kay> davidz: yeah, sure. i have that bug assigned too :) [Fr Okt 27 2006] [01:43:37] <davidz> so we're all in the same boat! [Fr Okt 27 2006] [01:43:48] <davidz> kay: anyway, thanks for asking around [Fr Okt 27 2006] [01:44:32] <kay> davidz: https://bugzilla.novell.com/show_bug.cgi?id=178321 [Fr Okt 27 2006] [01:44:45] <kay> davidz: can you see it? [Fr Okt 27 2006] [01:45:06] <davidz> ydah [Fr Okt 27 2006] [01:45:10] <davidz> yeah even [Fr Okt 27 2006] [01:45:17] <davidz> I have a RH bug about it too [Fr Okt 27 2006] [01:45:24] <davidz> but, uh, it's not public [Fr Okt 27 2006] [01:46:06] <kay> I'll ask Jan tomorrow, he tried to patch the tools to give us the needed data ... [Fr Okt 27 2006] [01:46:31] <davidz> uhh, the Novell bugzilla asks for "Company" when I tried creating an account
signature.asc
Description: OpenPGP digital signature
