linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephane Bunel <stephane.bunel@forumdesimages.fr>
To: Beolach <beolach@gmail.com>
Cc: Neil Brown <neilb@suse.de>, linux-raid@vger.kernel.org
Subject: Re: mdadm --detail showing annoying device
Date: Tue, 03 Nov 2009 13:16:22 +0100	[thread overview]
Message-ID: <4AF01F16.7000106@forumdesimages.fr> (raw)
In-Reply-To: <aebf5d970911030209l4a99c4f3xd0c4618dbcb5e41@mail.gmail.com>

Beolach a écrit :
> On Tue, Nov 3, 2009 at 02:37, Stephane Bunel
> <stephane.bunel@forumdesimages.fr> wrote:
>> Neil Brown a écrit :
>> (...)
>>
>>> 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.
>> All files in /dev/char are symlinks (see below). Rules are comming from
>> Gentoo.
>>
>>> 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.
>> Considering mdadm is only involved by "real" block device file, why not just
>> skipping symlink ?
>>
>>  o Udev rules used to rename /dev/sd[ab]:
>>
>> #cat 65-persistent-block.rules
>> ENV{PHYSDEVPATH}=="/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0",
>> NAME="raid_disk0"
>>
>> ENV{PHYSDEVPATH}=="/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0",
>> NAME="raid_disk1"
>>
> 
> Try prepending SUBSYSTEM=="block" to those, so they they'll only match
> the (block) sd* devices, and not the (char) sg? devices:
> SUBSYSTEM=="block",
> ENV{PHYSDEVPATH}=="/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0",
> NAME="raid_disk0"
> SUBSYSTEM=="block",
> ENV{PHYSDEVPATH}=="/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0",
> NAME="raid_disk1"

Well done!! This correct the sg* link issue.

#mdadm --detail /dev/md0
(...)
     Number   Major   Minor   RaidDevice State
        0       8        0        0      active sync   /dev/block/8:0
        1       8       16        1      active sync   /dev/block/8:16
(...)

But we loop back to the original problem. mdadm show '/dev/block/8:0' instead 
of '/dev/raid_disk0' (as i wish). This because the symlink '/dev/block/8:0' is 
shorter than the real block file name '/dev/raid_disk0'.

Actual heuristic prevents renaming of real block device name as desired under 
penalty of seeing symlinks from /dev/block/*.

maybe mdadm could change this behavior by:

  o always prefers real bloc file over symlinks.
  o simply skips symlinks.
  o changing the heuristic like proposed by my patch (prefer the name that is 
closer to /dev).


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-11-03 12:16 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
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 [this message]
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=4AF01F16.7000106@forumdesimages.fr \
    --to=stephane.bunel@forumdesimages.fr \
    --cc=beolach@gmail.com \
    --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).