linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephane Bunel <stephane.bunel@forumdesimages.fr>
To: Neil Brown <neilb@suse.de>
Cc: linux-raid@vger.kernel.org
Subject: Re: mdadm --detail showing annoying device
Date: Thu, 22 Oct 2009 13:22:52 +0200	[thread overview]
Message-ID: <4AE0408C.3090500@forumdesimages.fr> (raw)
In-Reply-To: <19167.33065.766493.889406@notabene.brown>

Neil Brown a écrit :
> On Wednesday October 21, stephane.bunel@forumdesimages.fr 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.

> 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)

   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.

   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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2009-10-22 11:22 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-17 22:34 2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) Justin Piszcz
2009-10-18 20:17 ` Justin Piszcz
2009-10-19  3:04   ` Dave Chinner
2009-10-19 10:18     ` Justin Piszcz
2009-10-20  0:33       ` Dave Chinner
2009-10-20  8:33         ` Justin Piszcz
2009-10-21 10:19           ` Justin Piszcz
2009-10-21 14:17             ` mdadm --detail showing annoying device Stephane Bunel
2009-10-21 21:46               ` Neil Brown
2009-10-22 11:22                 ` Stephane Bunel [this message]
2009-10-29  3:44                   ` Neil Brown
2009-11-03  9:37                     ` Stephane Bunel
2009-11-03 10:09                       ` Beolach
2009-11-03 12:16                         ` Stephane Bunel
2009-10-22 11:29                 ` Mario 'BitKoenig' Holbe
2009-10-22 14:17                   ` Stephane Bunel
2009-10-22 16:00                     ` Stephane Bunel
2009-10-22 22:49             ` 2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) Justin Piszcz
2009-10-22 23:00               ` Dave Chinner
2009-10-26 11:24               ` Justin Piszcz
2009-11-02 21:46                 ` Justin Piszcz
2009-11-20 20:39             ` 2.6.31+2.6.31.4: XFS - All I/O locks up to D-state after 24-48 hours (sysrq-t+w available) - root cause found = asterisk Justin Piszcz
2009-11-20 23:44               ` Bug#557262: " Faidon Liambotis
2009-11-20 23:51                 ` Justin Piszcz
2009-11-21 14:29                 ` Roger Heflin
2009-11-24 13:08 ` Which kernel options should be enabled to find the root cause of this bug? Justin Piszcz
2009-11-24 15:14   ` Eric Sandeen
2009-11-24 16:20     ` Justin Piszcz
2009-11-24 16:23       ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4AE0408C.3090500@forumdesimages.fr \
    --to=stephane.bunel@forumdesimages.fr \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).