md_component_detection = 1

md_component_detection = 1

[shahid shaikh]

[-- Attachment #1: Type: text/plain, Size: 1471 bytes --]




Hello Chris,

    I have written a sample psuedo driver which is basically consolidating
multiple paths to LUNs.
So I need prevent SCSI devices from scanning.

I gone thro' lvm.conf and found out that md is doing the similar thing by
setting following value in lvm.conf

         md_component_detection = 1
this parameter, if set, prevents scanning of all the SCSI devices
contributed in the creation of md.

So is there any parameter in LVM2 or device mapper, setting or clearing
which can prevent scanning of SCSI devices used for my psuedo driver.
Obviously other than filtering it out.

Thanks and Regards,
Shahid Shaikh.
Software Engineer.



http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________

This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete  this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at netadmin@patni.com and delete this mail. 
_____________________________________________________________________

[-- Attachment #2: Type: text/plain, Size: 93 bytes --]

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: md_component_detection = 1

[Christophe Varoqui]

All I can comment is LVM over the multipath implementation from 
Alasdair, RedHat.

For that, you need to set in /etc/lvm/lvm.conf :

    scan = [ "/dev", "/dev/mapper" ]  (you may or may not need this one, 
depending on your distro)
    filter = [ "r/sd.*/", "a/.*/" ]
    types = [ "device-mapper", 254 ]

Here the 254 may vary depending on your setup. To find out for your 
case, do :

[root@cl039 root]# grep mapper /proc/devices
254 device-mapper

Then everything should work as expected :

[root@cl039 root]# multipath -l -v2
red (3600a0b80000b596a000003113d9c5381)
[size=33 GB][features="0"][hwhandler="0"]
\_ round-robin 0 [enabled][first]
  \_ 4:0:3:9 sdan 66:112  [ready ][active]
  \_ 5:0:1:9 sdbh 67:176  [ready ][active]
\_ round-robin 0 [enabled]
  \_ 5:0:3:9 sdcb 68:240  [ready ][active]
  \_ 4:0:1:9 sdt  65:48   [ready ][active]

[root@cl039 root]# pvcreate /dev/mapper/red
  Physical volume "/dev/mapper/red" successfully created

[root@cl039 root]# pvscan
  PV /dev/mapper/red         lvm2 [33.86 GB]
  Total: 1 [33.86 GB] / in use: 0 [0   ] / in no VG: 1 [33.86 GB]


That's the more precise info I can share onn the subject.
Now your on your own.

Regards,
cvaroqui


shahid shaikh wrote:

>
>Hello Chris,
>
>    I have written a sample psuedo driver which is basically consolidating
>multiple paths to LUNs.
>So I need prevent SCSI devices from scanning.
>
>I gone thro' lvm.conf and found out that md is doing the similar thing by
>setting following value in lvm.conf
>
>         md_component_detection = 1
>this parameter, if set, prevents scanning of all the SCSI devices
>contributed in the creation of md.
>
>So is there any parameter in LVM2 or device mapper, setting or clearing
>which can prevent scanning of SCSI devices used for my psuedo driver.
>Obviously other than filtering it out.
>
>Thanks and Regards,
>Shahid Shaikh.
>Software Engineer.
>
>
>
>http://www.patni.com
>World-Wide Partnerships. World-Class Solutions.
>_____________________________________________________________________
>
>This e-mail message may contain proprietary, confidential or legally
>privileged information for the sole use of the person or entity to
>whom this message was originally addressed. Any review, e-transmission
>dissemination or other use of or taking of any action in reliance upon
>this information by persons or entities other than the intended
>recipient is prohibited. If you have received this e-mail in error
>kindly delete  this e-mail from your records. If it appears that this
>mail has been forwarded to you without proper authority, please notify
>us immediately at netadmin@patni.com and delete this mail. 
>_____________________________________________________________________
>  
>
>------------------------------------------------------------------------
>
>--
>dm-devel mailing list
>dm-devel@redhat.com
>https://www.redhat.com/mailman/listinfo/dm-devel
>


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: md_component_detection = 1

[Alasdair G Kergon]

On Tue, Feb 15, 2005 at 10:20:19PM +0100, christophe varoqui wrote:
>    types = [ "device-mapper", 254 ]
 
The number is actually related to the partitioning allowed on the device.

 * Devices are only checked for partition tables if their minor number
 * is a multiple of the number corresponding to their type below
 * i.e. this gives the granularity of whole-device minor numbers.
 * Use 1 if the device is not partitionable.

device-mapper devices don't get partitioned by the kernel
so use 1 instead of 254.

Alasdair
-- 
agk@redhat.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: md_component_detection = 1

[Christophe Varoqui]

Alasdair G Kergon wrote:

>On Tue, Feb 15, 2005 at 10:20:19PM +0100, christophe varoqui wrote:
>  
>
>>   types = [ "device-mapper", 254 ]
>>    
>>
> 
>The number is actually related to the partitioning allowed on the device.
>
> * Devices are only checked for partition tables if their minor number
> * is a multiple of the number corresponding to their type below
> * i.e. this gives the granularity of whole-device minor numbers.
> * Use 1 if the device is not partitionable.
>
>device-mapper devices don't get partitioned by the kernel
>so use 1 instead of 254.
>
>  
>
Ah, thank you for pointing this out.
Will update the FAQ accordingly.

regards,
cvaroqui

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Re: A better solution than "md_component_detection = 1"

[Lars Marowsky-Bree]

On 2005-02-15T20:17:10, shahid shaikh <shahid.shaikh@patni.com> wrote:

Sorry about this late reply, but I just stumbled across this post.

To recap, the issue is that we want to prevent LVM2/EVMS2 etc from
scanning (and using!) the raw physical devices if those are already
claimed/used by multipath.

LVM2 has a special handling for md_component_detection already; what I
want to propose in the following is a bit more general, and I've
discussed it with Hannes before.

Problem: A general solution for finding out whether another component is
using the device we're looking at.

Proposed solution: Introduce sub-devices into the sysfs tree. (And,
automatically, backlink those to parent devices, but that's just so the
tree can be traversed in any order.)

For example, /sys/block/sda would have a sub/ directory with "dm-0" in
there, pointing at /sys/block/dm-0 (surprise). The
/sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
thing.

This would also allow us to handle partitions in DM better: as all
linear mappings on top of /dev/dm-0 would show up in block/dm-0/sub/ and
vice versa.

md could work the same: block/sys/md0/parent/ would list all the devices
(or partitions) which it consists of.

This very simple(?) change would make a number of things much easier to
figure out.


Caveats:

- This obviously only works if the devices are already active, not if
  the specific user is offline; if LVM2 scans before multipath-tools has
  worked its magic, it won't work. 
  
  (But then, multipath-tools can figure out that there's already someone
  else using the raw physical device and not mess with it! Woho, world
  saved!)

- This ONLY exports very rudimentary hierarchical information; it won't
  tell you what the device is used for or how. However, that information
  alone would be very helpful already.
  

Greg, Alasdair? List?


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

A better solution than "md_component_detection = 1"

[Lars Marowsky-Bree]

On 2005-04-10T19:29:31, Lars Marowsky-Bree <lmb@suse.de> wrote:

This has generated absolutely no comments, so I'm resending it...

> On 2005-02-15T20:17:10, shahid shaikh <shahid.shaikh@patni.com> wrote:
> 
> Sorry about this late reply, but I just stumbled across this post.
> 
> To recap, the issue is that we want to prevent LVM2/EVMS2 etc from
> scanning (and using!) the raw physical devices if those are already
> claimed/used by multipath.
> 
> LVM2 has a special handling for md_component_detection already; what I
> want to propose in the following is a bit more general, and I've
> discussed it with Hannes before.
> 
> Problem: A general solution for finding out whether another component is
> using the device we're looking at.
> 
> Proposed solution: Introduce sub-devices into the sysfs tree. (And,
> automatically, backlink those to parent devices, but that's just so the
> tree can be traversed in any order.)
> 
> For example, /sys/block/sda would have a sub/ directory with "dm-0" in
> there, pointing at /sys/block/dm-0 (surprise). The
> /sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
> thing.
> 
> This would also allow us to handle partitions in DM better: as all
> linear mappings on top of /dev/dm-0 would show up in block/dm-0/sub/ and
> vice versa.
> 
> md could work the same: block/sys/md0/parent/ would list all the devices
> (or partitions) which it consists of.
> 
> This very simple(?) change would make a number of things much easier to
> figure out.
> 
> 
> Caveats:
> 
> - This obviously only works if the devices are already active, not if
>   the specific user is offline; if LVM2 scans before multipath-tools has
>   worked its magic, it won't work. 
>   
>   (But then, multipath-tools can figure out that there's already someone
>   else using the raw physical device and not mess with it! Woho, world
>   saved!)
> 
> - This ONLY exports very rudimentary hierarchical information; it won't
>   tell you what the device is used for or how. However, that information
>   alone would be very helpful already.
>   
> 
> Greg, Alasdair? List?
> 
> 

Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

Re: A better solution than "md_component_detection = 1"

[christophe varoqui]

> > 
> > For example, /sys/block/sda would have a sub/ directory with "dm-0" in
> > there, pointing at /sys/block/dm-0 (surprise). The
> > /sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
> > thing.
> > 
> > This would also allow us to handle partitions in DM better: as all
> > linear mappings on top of /dev/dm-0 would show up in block/dm-0/sub/ and
> > vice versa.
> > 
> > md could work the same: block/sys/md0/parent/ would list all the devices
> > (or partitions) which it consists of.
> > 
Regardless of the implementation, am I the only one to think that
dm-0/parent/ should contain "parents of dm-0" ? :)

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: A better solution than "md_component_detection = 1"

[Lars Marowsky-Bree]

On 2005-04-19T23:55:55, christophe varoqui <christophe.varoqui@free.fr> wrote:

> > > For example, /sys/block/sda would have a sub/ directory with "dm-0" in
> > > there, pointing at /sys/block/dm-0 (surprise). The
> > > /sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
> > > thing.
> > > 
> > > This would also allow us to handle partitions in DM better: as all
> > > linear mappings on top of /dev/dm-0 would show up in block/dm-0/sub/ and
> > > vice versa.
> > > 
> > > md could work the same: block/sys/md0/parent/ would list all the devices
> > > (or partitions) which it consists of.
> > > 
> Regardless of the implementation, am I the only one to think that
> dm-0/parent/ should contain "parents of dm-0" ? :)

I thought that was exactly what I was proposing.


Sincerely,
    Lars Marowsky-Brée <lmb@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business

Re: A better solution than "md_component_detection = 1"

[christophe varoqui]

On mer, 2005-04-20 at 12:13 +0200, Lars Marowsky-Bree wrote:
> On 2005-04-19T23:55:55, christophe varoqui <christophe.varoqui@free.fr> wrote:
> 
> > > > For example, /sys/block/sda would have a sub/ directory with "dm-0" in
> > > > there, pointing at /sys/block/dm-0 (surprise). The
> > > > /sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
> > > > thing.
> > > > 
> > > > This would also allow us to handle partitions in DM better: as all
> > > > linear mappings on top of /dev/dm-0 would show up in block/dm-0/sub/ and
> > > > vice versa.
> > > > 
> > > > md could work the same: block/sys/md0/parent/ would list all the devices
> > > > (or partitions) which it consists of.
> > > > 
> > Regardless of the implementation, am I the only one to think that
> > dm-0/parent/ should contain "parents of dm-0" ? :)
> 
> I thought that was exactly what I was proposing.
> 
I mean the following would be more friendly to me.

/sys/block/sda/parent/dm-0
/sys/block/sdb/parent/dm-0
/sys/block/dm-0/sub/sd[ab]

In your proposed example, "parent" in fact means "parents of" and "sub"
means "sub of" ... which I find misleading.

But may be that's just me :)

Regards,
-- 
christophe varoqui <christophe.varoqui@free.fr>

Re: A better solution than "md_component_detection = 1"

[Greg KH]

On Sun, Apr 10, 2005 at 07:29:31PM +0200, Lars Marowsky-Bree wrote:
> Proposed solution: Introduce sub-devices into the sysfs tree. (And,
> automatically, backlink those to parent devices, but that's just so the
> tree can be traversed in any order.)
> 
> For example, /sys/block/sda would have a sub/ directory with "dm-0" in
> there, pointing at /sys/block/dm-0 (surprise). The
> /sys/block/dm-0/parent/sd{a,b} entries would do a very surprising
> thing.

I don't have a problem with this, and I don't think udev would either.
There's nothing keeping this from happening today with regards to the
sysfs code.

thanks,

greg k-h

Re: A better solution than "md_component_detection = 1"

[Lars Marowsky-Bree]

On 2005-04-10T19:29:31, Lars Marowsky-Bree <lmb@suse.de> wrote:

Just so that it doesn't get lost:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=156679

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX Products GmbH - A Novell Business	 -- Charles Darwin
"Ignorance more frequently begets confidence than does knowledge"