On Thursday October 22, stephane.bunel@xxxxxxxxxxxxxxxxx wrote: > Neil Brown a écrit : > > On Wednesday October 21, stephane.bunel@xxxxxxxxxxxxxxxxx wrote: > >> Hi, > >> > >> I'm a newbie in the mdadm world. I defined some udev rules to make disk > >> staticly named according to the bus/host/target. I.e. /dev/sda become > >> /dev/raid_disk0. So nothing very special with that, it's just a convenient way > >> to assign disk name to it's physical location. > >> > >> #ls -la /dev/raid* > >> brw-rw---- 1 root disk 8, 0 2009-10-16 18:12 /dev/raid_disk0 > >> brw-rw---- 1 root disk 8, 16 2009-10-16 18:12 /dev/raid_disk1 > >> > >> A RAID1 (/dev/md0) is assembled over this two disk. > >> When looking for detailed information, mdadm show annoying device name in > >> place of /dev/raid_disk*: > >> > > .... > >> Number Major Minor RaidDevice State > >> 0 8 0 0 active sync /dev/char/21:0 > >> 1 8 16 1 active sync /dev/char/21:1 > > > > What is a block device doing in /dev/char ??? There should only be > > character devices in there. > > > > If these are actually block device, then I think there is something > > wrong with your udev rules. > > I think my udev rules are not in cause because they just change /dev/sd* to > /dev/raid_disk*. For udev /dev/char/21:0 seems correspond to the generic scsi > device driver (sg) wich is binded to scsi devices. That doesn't answer the question of why a block device is appearing in /dev/char/. My guess (which is quite possibly wrong, but it is the best I can do) is that whatever change to udev.rules that you made to get /dev/sdXX to be renamed to /dev/raid_diskXX, also renamed the scsi-generic devices to be /dev/raid_diskXX. I think that would have the effect that you are seeing. > > > If these are char devices, then mdadm is doing the wrong thing, but I > > cannot see that from the code. > > mdadm by choosing the shorter name without differentiate path (/dev/.../ ) > and name (sda) choose /dev/char/21:0 just because it is shorter than > /dev/raid_disk0. > > > Your proposal of choosing the highest rather than the shortest name > > has some merit, but I your current situation doesn't seem to justify > > it, and I particularly like the simplicity of the current heuristic. > > My proposal doesn't choose the highest name but does a selection based on > the shortest path to the device name. I.e. my proposal choose: > > /dev/raid_disk0 (1 directory level) over /dev/char/21:0 (2 directory level) > /dev/raid_disk0 (1 directory level) over /dev/block/8:0 (2 directory level) > /dev/sda1 (1 directory level) over /dev/disk/by-label/BOOT (3 directory level) This is what I meant by 'highest'. highest up in the directory tree - closest to the root (I guess some people might think that being close to the root is 'low', not 'high :-) > > So in fact, my proposal doesn't change current situation but "adjust" the > heuristic to avoid seeing an annoying device name (char device) as a member of > raid just because it's fullname is shorter than a "semantically better" name. I appreciate that. I am not against changing the heuristic if I find a good reason ... particularly if I can find something that actually measures "semantic goodness"! But I don't think you have provided a good reason. /dev/char/21:0 should be a char device, not a block device. So mdadm should ignore it. On your system, /dev/char/21:0 is a block device (or a link to a block device) so there is clearly some sort of configuration error. If you still cannot find it, maybe you could show us the change you made to udev.rules, and an 'ls -l' of '/dev/char'. That might help shed some light on your situation. NeilBrown > > Add a printf in map_dev() show that my proposal seems help the heuristic to > be more robust in case of "advanced" device naming, without changing current > things. > > > #./mdadm --detail /dev/md0 > (/dev/char/21:0) > (/dev/block/8:0) > (/dev/disk/by-id/ata-Hitachi_HDP725050GLA360_GEA534RJ37D3RA) > (/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA534RJ37D3RA) > (/dev/raid_disk0) > (/dev/char/21:1) > (/dev/block/8:16) > (/dev/raid_disk1) > (/dev/disk/by-id/ata-Hitachi_HDP725050GLA360_GEA534RJ36T9VA) > (/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA534RJ36T9VA) > /dev/md0: > Version : 0.90 > Creation Time : Tue Oct 13 12:53:54 2009 > Raid Level : raid1 > Array Size : 488386496 (465.76 GiB 500.11 GB) > Used Dev Size : 488386496 (465.76 GiB 500.11 GB) > Raid Devices : 2 > Total Devices : 2 > Preferred Minor : 0 > Persistence : Superblock is persistent > > Update Time : Thu Oct 22 12:42:44 2009 > State : clean > Active Devices : 2 > Working Devices : 2 > Failed Devices : 0 > Spare Devices : 0 > > UUID : 3fea95a0:e1b8a341:3b119117:e416f62b > Events : 0.1526 > > Number Major Minor RaidDevice State > 0 8 0 0 active sync(/dev/char/21:0) > (/dev/block/8:0) > (/dev/disk/by-id/ata-Hitachi_HDP725050GLA360_GEA534RJ37D3RA) > (/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA534RJ37D3RA) > (/dev/raid_disk0) > /dev/raid_disk0 > 1 8 16 1 active sync(/dev/char/21:1) > (/dev/block/8:16) > (/dev/raid_disk1) > (/dev/disk/by-id/ata-Hitachi_HDP725050GLA360_GEA534RJ36T9VA) > (/dev/disk/by-id/scsi-SATA_Hitachi_HDP7250_GEA534RJ36T9VA) > /dev/raid_disk1 > > > > Thanks, > Stéphane Bunel. > -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
