Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 134483 - Could extra GPFS patches be included
Could extra GPFS patches be included
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kiersten (Kerri) Anderson
Brian Brock
: FutureFeature, Reopened
Depends On:
  Show dependency treegraph
Reported: 2004-10-03 20:32 EDT by Dag Wieers
Modified: 2007-11-30 17:07 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-10-19 15:17:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dag Wieers 2004-10-03 20:32:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922 Galeon/1.3.17

Description of problem:
We're doing a lot of GPFS deployements lately with Red hat Enterprise
Linux and I'm wondering whether the advertized patches
(http://www-124.ibm.com/linux/patches/?project_id=132) from IBM are
(still) useful with recent RHEL3 kernels and why, if so, they are not
included by default.

I know this should be (also?) a question to the IBM GPFS people, but I
figured this is something Red Hat would be interested in too. Having
to patch, build and install a new kernel makes automated mass
installations currently a major PITA.

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

How reproducible:

Steps to Reproduce:
1. ...

Additional info:
Comment 1 Rik van Riel 2004-10-03 22:03:50 EDT
Dag, if we included GPFS in RHEL3, people would also want us to
include it in RHEL4, RHEL5, RHEL6, etc.

It would not be a good use of our resources if we let hundreds of
features "pile up" like this, increasing our burden in the patches we
need to maintain and reducing our ability to fix actual problems
customers run into, as well as reducing our ability to help develop
the upstream kernel.

In order for GPFS to even be considered as a RHEL feature, IBM should
make some serious efforts at getting GPFS integrated into the upstream

Once GPFS is in the upstream kernel, it might be technically feasible
for Red Hat to support it and all that needs to get it added to RHEL
is a business justification ;)

Anyway, the first step is to get GPFS merged into the upstream kernel.
Comment 2 Arjan van de Ven 2004-10-04 01:50:36 EDT
(also, GPFS is a binary only module)
Comment 3 Dag Wieers 2004-10-04 05:13:17 EDT
Hi Rik, Arjan,

I'm sorry for not being clear. These patches are not exactly GPFS, but
changes GPFS requires to work properly. The description and the
patches are available from the URL I provided.

I was wondering if these patches make any sense (even for non-gpfs
users). They seem not directly GPFS related anyway. Please don't let
the GPFS-tag influence your opinion, as I'd like to have your
untainted opinion :)

 * mmap-invalidate
   Include mmap invalidate functionality that is necessary when
   performing mmap writes with a parallel filesystem.

 * NFS lockd support for filesystem locking
   NFS advisory locking is performed by lockd on the exporting node.
   It currently does its own local locking without regard to the
   filesystem. Linux provides a lock file operation that is used by
   non-NFS lock routines to allow the exporting filesystem to handle
   such locks. In the case of distributed filesystems like GPFS, this
   is essential because locking on other nodes must be taken into
   consideration when responding to lock requests. This patch adds
   the lock calls that are necessary for correct operation over NFS.

 * nfsd-attr
   Fixes nfsd to return correct file attributes when NFS exporting
   a GPFS filesystem that is mounted on more than one node
   (multi-node mode).

PS I fully understand your concern to not add and have to support
custom patches. Also the GPFS modules (GPFS compatibility layer) are
actually GPL and the latest source, if you care, can be found at: 
(the gpfs.gpl RPM with sourcecode is inside the tarball)

Comment 4 Rik van Riel 2004-10-04 08:15:12 EDT
We have some patches like these, for GFS (which is GPL), but have no
intentions of adding patches to accomodate binary only drivers.

This is not because we don't like binary only drivers, but because
binary only drivers are in a legally grey area. As a company that
relies on pure open source, we cannot afford to deal in borderline
legal patches. Sorry.
Comment 5 Dag Wieers 2004-10-04 08:31:06 EDT
Well, either these patches are useful in the general case, or they are
not. Your response always comes back to something that is partial and
irrelevant to the issue. (Mind you that these patches are also GPL)

By ignoring my question do I correctly understand that you think these
patches are irrelevant to Linux ?

Then, would these GFS patches you mentioned provide the same
functionality that GPFS needs ? If not, what is the solution. If so, I
can tell the GPFS people to use another interface instead of their own
set of patches.

PS If this is not the right forum to discuss this, just say so.
Comment 9 Red Hat Bugzilla 2007-02-05 14:17:22 EST
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
Comment 10 RHEL Product and Program Management 2007-10-19 15:17:13 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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