Bug 79086

Would you please provide an update on this enhancement request?
Thanks.

Reiterating request for an update....

Heather, I recieved the following from Steven Tweetie:

I'd like to see a better explanation of exactly what end result they
want to achieve.  In theory we can easily do this --- we already have
a ton of per-major-number arrays to track device behaviour in the
kernel, and having a new one to construct the driver name from isn't
that big a stepforward.  But it's getting a bit late to be doing that
sort of surgeryon AS-2.1, especially if there are alternatives
possible in user space to do what they want.  And it would be a custom
hack --- I'd much rather see this discussed upstream in 2.6 before
making any decision on 2.4 backporting.
--Stephen

couldn't they just do something along the lines of what cciss does? 
Just keep track of how many times they call add_gendisk, and after X
iteration, modify the base name of the gendisk such that it provides a
non-wrapped name in /proc/partitions.

We received the recommendation to compile a patch, send it to the 
open source community, and request that the patch be considered for 
inclusion in the v2.6.x kernel.  If it were accepted in the v2.6.x 
kernnel, it would be easier for Red Hat to back-port it for inclusion 
in their v2.4.x distros.  
Per the PP team, the callback function for deriving a block 
device's name when called from disk_name() in fs/partition/check.c 
has already been added to the v2.6.x kernel and has been back-ported 
in some distributions.  
Would it be possible for you to do this without a patch from us?  

I've received an updated version of sysstat to work with in order to 
provide information needed to fix this within the RHEL 
distributions.  I'll provide this information as soon as I can.

Hi all, I am customer from Spain, and we have the same problem with
PowerPath 4.3 and Red Hat 3.0 U3. For example:

cat /proc/partitions | grep emcpowera
 233     0    4418880 emcpowera 16 36 128 10 0 0 0 0 0 10 10
 232     0    2208960 emcpowera 16 36 128 0 0 0 0 0 0 0 0

I agree with you if you can provide me some kind of information about
the evolution of this problems.

Best regards

*** Bug 140849 has been marked as a duplicate of this bug. ***

So if the callback function for deriving a block 
device's name when called from disk_name() in fs/partition/check.c is already
upstream in the 2.6x kernel, is this sufficient to address the issue in RHEL? Or
is there more work necessary?

J

Update....The PowerPath team has reviewed the Bugzilla.  They have 
told me that a patch has been compiled and is waiting for a code 
review.

Heather,

Is this a patch to powerpath that keeps track of how many times they call
add_gendisk, and after X iteration, modify the base name of the gendisk such
that it provides a non-wrapped name in /proc/partitions? Or is the patch you are
refering to the patch to the 2.6 kernel?

Can you get clarification from your engineers on this?

Thanks,
J

Hi JR - I pinged the PowerPath team for a response and am waiting for a 
response.  I'll update the Bugzilla again as soon as I receive a response.
-H

Also interested in having this backported to the 2.4 kernel for the RHEL 3.0 U4
and onwards series.

I'm expecting a patch from the PowerPath team and will post it to this bugzilla 
as soon as I receive it.

Created attachment 113713 [details]
Proposed patch from the PowerPath team for application to both RHEL 2.1 and 3.0

The proposed patch is to ensure that the emcpower partitions in
/proc/partitions are correct and prevents multiple entries from emcpowera to
emcpowerp.

PM ACK for U6

Excuse me, but 2.6 does *NOT* have such callbacks.  And will not have
them - they make absolutely no sense there, since we have disk->name
and driver can (and should) set it up to whatever it wants when it
registers a disk.   IOW, aforementioned "PP team" had been... well,
not quite in agreement with reality.

Note that we have several tools/utilities (more specifically, say LVM) assume
unique device names in 2.4 based kernel. If we don't solve this bugzilla one way
or the other, there'll be some un-specified io behaviors. For example:

In a real case, a customer (who was originally warned and knew about the 16
emcpower devices restriction) created 16 emcpower path devices intended to be
used by LVM. The devices first showed up as /dev/emcpower(a-p) with major 232.
Sometime later, due to configuration changes, he removed the first 4 devicdes
(/dev/emcpower(a-d)) and created four more devices, thinking he was ok under the
16-devices-limit but surprisingly found out he could only "see" 12 of them via
'lvmdiskscan" command. After the support ticket was logged, we found the lvmdiskscan

first checked the /proc/partitions and it looked like this:

233     0    1048576 emcpowera 134 96 1210 170 0 0 0 0 0 160 90
233    16    1048576 emcpowerb 134 96 1210 150 0 0 0 0 0 150 70
233    32    1048576 emcpowerc 131 97 1210 140 0 0 0 0 0 140 60
233    48    1048576 emcpowerd 131 97 1210 130 0 0 0 0 0 130 50
232    64    1048576 emcpowere 143 163 1366 200 0 0 0 0 0 200 90
232    80    1048576 emcpowerf 146 165 1376 200 0 0 0 0 0 200 90
232    96    1048576 emcpowerg 146 165 1376 170 0 0 0 0 0 170 70
232   112    1048576 emcpowerh 146 165 1376 220 0 0 0 0 0 220 120
232   128    1048576 emcpoweri 146 165 1376 200 0 0 0 0 0 200 100
232   144    1048576 emcpowerj 146 165 1376 160 0 0 0 0 0 160 60
232   160    1048576 emcpowerk 143 151 1338 120 0 0 0 0 0 120 40
232   176    1048576 emcpowerl 144 153 1344 130 0 0 0 0 0 130 50
232   192    1048576 emcpowerm 142 151 1336 120 0 0 0 0 0 120 60
232   208    1048576 emcpowern 146 156 1354 140 0 0 0 0 0 140 70
232   224    1048576 emcpowero 146 156 1354 150 0 0 0 0 0 140 50
232   240    1048576 emcpowerp 146 156 1354 150 0 0 0 0 0 150 70

Note the newly created power path devices had major *233* while the deleted
power path devices had major *232* with identical device names
(/dev/emcpower(a-d)). The lvmdiskscan took the first entry from /proc/partitions
and did an open("/dev/emcpowera", ...). The open system call dropped down to
linux VFS layer that searched the /dev directory and found the first
/dev/emcpowera (major 232). The open failed since physical device was not there.
The lvm checked the return code and then decided the first device in
/proc/partitions somehow offline so it dropped it and went on for next entry.
The /dev/powerpath(a-d) were then out of lvm's sight for good.

This is a simplified real case. However, it should be clear that it is not
feasible to comb thru the existing 2.4 based LVM code to "fix" and/or workaround
any instance like this. 

If this is a specific hook for EMC/Powerpath only then it's my understanding
that we would be put at risk with legal because of the GPL.  What is not clear
from the request is if they were using Powerpath as an example, suggesting that
it be made available for a larger audience.  I'm going to give EMC a call and
see if I can get more info, but based on the various comments throughout this
bugz, it appears to be a problem that should be addressed - but not with an
EMC/Powerpath specific hook.

Per the PowerPath team, the intent of the patch was to keep it generic so that 
any third party driver would be able to register a callback function for 
formatting its user exposed "name" in /proc/partitions correctly.

PowerPath naming conventions per version are as follows:

PowerPath 3.0.x uses power2 in /proc/devices
PowerPath 4.3.x uses emcp in /proc/devices
PowerPath 4.4.x uses power2 in /proc/devices 

*** Bug 142263 has been marked as a duplicate of this bug. ***

Changing version to RHEL3 since that's what this issue turned in to over time. 
Also, the patch has been submitted internally for review and possible inclusion
(barring any blocking issues with the patch) in RHEL3 U6.

A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-34.EL).

*** Bug 140849 has been marked as a duplicate of this bug. ***

The addition of this function call will still require an updated version of
PowerPath to solve the problem.  EMC is actively working on this and customers
will need to contact EMC for an update.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-663.html

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-663.html