On Fri, Jun 17, 2011 at 16:49, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, 2011-06-17 at 16:40 +0200, Kay Sievers wrote: >> Ok, the still remaining questions: >> >> Why isn't logging all symlink names during device discovery solving >> all the problems we discuss without any change to the kernel? It's >> just a single udev rule that can be added to ages old systems today. I >> think that solves exactly the same problem and works with many names >> at the same time. > > It could ... but that doesn't solve the prink problem or > the /proc/partitions one. The idea is to allow naive users to identify > their device physically when the system logs something about it. Having > to describe a manual mapping procedure is very complex for them. How? You see 'sda kaput' then you scroll up to the last udev message with /dev/disk/by-all-the-many-names/. Anyone who can't do this should not even get access to the log file. :) >> Where is "fred", "jim", and "betty" stored on bootup? > > So this is subsystem specific. For the case of a SCSI enclosure, I can > answer that it's actually burned into the enclosure firmware. When you > build an enclosure with labels, the label names are stored in a > diagnostic page. We can actually interrogate the enclosure directly or > use the ses driver to get these names mapped to current devices. To me this sounds like a nice name on top of the current bunch of names, not like a 'preferred' name. I still don't like to introduce any new facility to the kernel that can handle only one single name. Reality the last years has taught us a very different story, and we've walked a long way to get where we are. I really don't believe single names will ever work, it's just a nice theory. >> What are the keys to match the pretty names to the disks? >> >> The pretty name is a one-shot setting only? If not how is a change >> handled for already used devices? > > obviously, one device will be root, and it will already be used > as /dev/root, but the proposal isn't to change any name, it's merely to > set "fred" as the preferred name for /dev/root, which is also /dev/sdc > and /dev/disk/by-id/naa-566dce3ddf etc ... Sure, sounds nice. I just don't see how all that can be done automatically in a sane way. It's like telling people to name their network interfaces "internal", "external", "dmz". Almost nobody is doing this, there is even the netif alias support already, and nobody wants to use it besides a few SNMP tools. In my experience, stuff needs to work out-of-the-box, or it is not used. >> How will this information be available in the initramfs, where >> mutltiple disks might need to be mounted already? Initramfs images are >> generic and not created per host. > > That's initramfs specific. However, if, in deference to your new > location, we look at dracut, it has a modules directory for plugin > extensions. The scripts which do the mapping can be inserted there as > an additional rpm. That's not really what I meant. I want to hear how the decision is made which one of the multiple possibilities for the name composition is chosen. Ideally it needs to work in a generic setup, not with a customized host-specific file included even in the initramfs image. >> How are multipath setups handled where the exact same disk is behind >> multiple kernel devices? What to put into these names in this case? > > I'm not sure I understand the question. a md setup of RAID-1 on fred > and betty would assemble using /dev/disk/by-preferred/fred > and /dev/disk/by-preferred/betty. Whether the user want's to > call /dev/md0 something pretty is up to them ... it's not a physically > labelled entity, so I'd tend just to leave it with its default name as > the preferred name. I mean multi-path not raid. Disks have all the same ids, same locations, but we have multiple kernel devices for them. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
