Re: [PATCH 3/6] Create multipath.conf

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 01/20/2010 07:31 PM, David Lehman wrote:
> On Wed, 2010-01-20 at 19:03 -0500, Peter Jones wrote:
>> Revamp this since multipath is now writing our rules for us.
>>
>> Use device.serial/device.vendor/device.model where appropriate, and
>> don't give the device a braindead mode.  Also change /when/ we write the
>> files out.
>> ---
>>  storage/__init__.py         |   11 +
>>  storage/devicelibs/mpath.py |  517 +++----------------------------------------
>>  storage/devices.py          |   10 +-
>>  storage/devicetree.py       |   27 ++-
>>  4 files changed, 65 insertions(+), 500 deletions(-)
>>
>> diff --git a/storage/devicetree.py b/storage/devicetree.py
>> index 4356ca5..5fa68f6 100644
>> --- a/storage/devicetree.py
>> +++ b/storage/devicetree.py
>> @@ -1912,10 +1919,24 @@ class DeviceTree(object):
>>  
>>          # Having found all the disks, we can now find all the multipaths built
>>          # upon them.
>> -        for mp in self.__multipaths.values():
>> +        whitelist = []
>> +        mpaths = self.__multipaths.values()
>> +        mpaths.sort(key=lambda d: d.name)
>> +        for mp in mpaths:
>>              log.info("adding mpath device %s" % mp.name)
>>              mp.setup()
>> +            whitelist.append(mp.name)
>> +            for p in mp.parents:
>> +                self.addIgnoredDisk(p)
> 
> I thought it was decided today that mpath member disks should not be
> ignored, since that's the case for biosraid member disks.

Was it?  I thought we decided that multipath members shouldn't be
automatically filtered out by isIgnored(), since that prevents them from
being recognized in addUdevDevice(), which we need to process them.  But
once we've done that, /manually/ ignoring them doesn't have the same
problem.

That being said, I am beginning to suspect that this may not be the right
way to accomplish what I was going for here, so if you really think I should
take that part out, I'm open to that.

-- 
        Peter

What we need is either less corruption, or more chances to
participate in it.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux