Bug 79086 - Request for enhancement for callback function
Request for enhancement for callback function
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Doug Ledford
: FutureFeature
Depends On:
Blocks: 156320
  Show dependency treegraph
 
Reported: 2002-12-05 09:49 EST by Heather Conway
Modified: 2007-11-30 17:06 EST (History)
24 users (show)

See Also:
Fixed In Version: RHSA-2005-663
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-28 16:41:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Proposed patch from the PowerPath team for application to both RHEL 2.1 and 3.0 (4.00 KB, patch)
2005-04-27 09:07 EDT, Heather Conway
no flags Details | Diff

  None (edit)
Description Heather Conway 2002-12-05 09:49:56 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Description of problem:
Enhancement request for you to allow a callback function for deriving a block 
device's name when called from disk_name() in fs/partition/check.c.  This would 
allow for block device drivers such as our PowerPath product to control the 
device naming used in /proc/partitions and iostat(1).  

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
Enhancement request for you to allow a callback function for deriving a block 
device's name when called from disk_name() in fs/partition/check.c.  This would 
allow for block device drivers such as our PowerPath product to control the 
device naming used in /proc/partitions and iostat(1).  	

Additional info:
Comment 1 Heather Conway 2004-04-22 09:15:29 EDT
Would you please provide an update on this enhancement request?
Thanks.
Comment 2 Heather Conway 2004-05-20 08:21:42 EDT
Reiterating request for an update....
Comment 3 Greg Nuss 2004-05-20 12:29:58 EDT
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
Comment 10 Neil Horman 2004-08-31 16:40:04 EDT
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.
Comment 11 Heather Conway 2004-11-10 14:27:20 EST
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?  
Comment 12 Heather Conway 2004-11-10 14:28:36 EST
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.
Comment 13 Llorens Vanaclocha 2004-12-03 08:53:10 EST
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
Comment 14 Tom Coughlan 2004-12-17 11:46:48 EST
*** Bug 140849 has been marked as a duplicate of this bug. ***
Comment 15 Johnray Fuller 2004-12-22 09:40:06 EST
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
Comment 17 Heather Conway 2005-01-28 09:57:34 EST
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.
Comment 19 Johnray Fuller 2005-02-15 18:52:14 EST
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
Comment 21 Heather Conway 2005-03-03 16:00:57 EST
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
Comment 22 Elson, Del 2005-03-29 23:22:43 EST
Also interested in having this backported to the 2.4 kernel for the RHEL 3.0 U4
and onwards series.
Comment 27 Heather Conway 2005-04-22 11:17:55 EDT
I'm expecting a patch from the PowerPath team and will post it to this bugzilla 
as soon as I receive it.
Comment 28 Heather Conway 2005-04-27 09:07:35 EDT
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.
Comment 32 Marty Wesley 2005-05-26 02:44:34 EDT
PM ACK for U6
Comment 37 Alexander Viro 2005-06-06 11:55:40 EDT
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.
Comment 42 Wendy Cheng 2005-06-10 12:08:45 EDT
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. 
Comment 46 Chris Jones 2005-06-14 11:51:30 EDT
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.
Comment 48 Heather Conway 2005-06-17 07:34:43 EDT
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.
Comment 49 Heather Conway 2005-06-17 08:25:38 EDT
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 
Comment 70 Doug Ledford 2005-07-07 18:57:40 EDT
*** Bug 142263 has been marked as a duplicate of this bug. ***
Comment 79 Doug Ledford 2005-07-23 17:19:14 EDT
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.
Comment 81 Ernie Petrides 2005-07-28 22:15:26 EDT
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).
Comment 82 Ernie Petrides 2005-07-28 22:20:25 EDT
*** Bug 140849 has been marked as a duplicate of this bug. ***
Comment 93 Rob Kenna 2005-08-25 11:35:17 EDT
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.
Comment 96 Red Hat Bugzilla 2005-09-28 10:15:39 EDT
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
Comment 97 Red Hat Bugzilla 2005-09-28 16:18:17 EDT
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

Note You need to log in before you can comment on or make changes to this bug.