Red Hat Bugzilla – Bug 134483
Could extra GPFS patches be included
Last modified: 2007-11-30 17:07:04 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
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):
Steps to Reproduce:
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.
(also, GPFS is a binary only module)
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 :)
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.
Fixes nfsd to return correct file attributes when NFS exporting
a GPFS filesystem that is mounted on more than one node
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)
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.
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.
REOPENED status has been deprecated. ASSIGNED with keyword of Reopened is preferred.
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.