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 435469 - gfs_tool: Cannot allocate memory
gfs_tool: Cannot allocate memory
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs (Show other bugs)
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Robert Peterson
GFS Bugs
Depends On:
Blocks: 438762
  Show dependency treegraph
Reported: 2008-02-29 10:43 EST by Robert Hurst
Modified: 2010-01-11 22:16 EST (History)
1 user (show)

See Also:
Fixed In Version: RHBA-2008-0804
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-25 15:28:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to fix the problem (731 bytes, patch)
2008-03-25 14:30 EDT, Robert Peterson
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2008:0804 normal SHIPPED_LIVE GFS bug fix update 2008-07-25 15:28:17 EDT

  None (edit)
Description Robert Hurst 2008-02-29 10:43:34 EST
Description of problem:
`gfs_tool df /home` and `gfs_tool gettune /home` return an error that it cannot
allocate memory on some of our systems.

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

How reproducible:
On systems with not much "free" memory, but still has a lot of "cached" memory.

Steps to Reproduce:
1. free -mt
2. gfs_tool df /home
3. gfs_tool gettune /home

Actual results:
open("/home", O_RDONLY)                 = 3
ioctl(3, 0x4723, 0x7fbffcdf3c)          = 0
ioctl(3, 0x472d, 0x7fbfffe300)          = -1 ENOMEM (Cannot allocate memory)

Expected results:
open("/home", O_RDONLY)                 = 3
ioctl(3, 0x4723, 0x7fbffdf73c)          = 0
ioctl(3, 0x472d, 0x7fbffff760)          = 719
close(3)                                = 0

Additional info:
The gfs_tool does most of its work using ioctl calls to the gfs kernel module. 
Often, it tries to allocate and pass in a huge buffer to make sure it doesn't
ask for more than the kernel needs to respond with.

In some cases, it doesn't need to allocate such a big buffer. I fixed "gfs_tool
counters" for a similar ENOMEM problem with bugzilla record 229461 about a year
ago.  (I don't know if that bug record is public or locked so you may not be
able to access it, which is out of my control--sorry).

I should probably go through all the other gfs_tool functions, including the two
you mentioned, and figure out their minimum memory requirements and change the
code so it doesn't ask for so much memory.
Comment 1 Robert Peterson 2008-02-29 11:29:42 EST
Reassigning to me.  The "additional info" comments are mine from
linux-cluster mailing list.  Thanks, Robert.
Comment 2 Robert Peterson 2008-03-24 14:04:35 EDT
Checking the code and doing some testing reveal that the "df" and
"gettune" functions of gfs_tool should both work if given a 4K buffer
rather than 64K.  The fix should be as easy as changing gfs_tool/df.c
and gfs_tool/tune.c to change the constant SIZE at the top from (65536)
to (4096).  Now I just need to fit it in with everything else going on.
Comment 3 Robert Peterson 2008-03-25 10:47:52 EDT
Requesting flags so I can get this fix into RHEL4.7.
Comment 4 RHEL Product and Program Management 2008-03-25 10:48:11 EDT
This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".
Comment 5 Robert Peterson 2008-03-25 14:30:03 EDT
Created attachment 299056 [details]
patch to fix the problem

This is the patch I'm planning to ship.  I've tested it on one of my
trin nodes and it works.
Comment 6 Robert Peterson 2008-03-25 14:38:10 EDT
The patch was pushed to the cluster git repository so it should
hopefully go into RHEL4.7 and similar.  I've cloned this bug as
bug #438762 for crosswriting the changes into RHEL5.2.  I'll push it
into  the upstream branches (master, STABLE2) using that bz record,
not this one.  Since this is pushed, I'm changing the status to
Comment 9 errata-xmlrpc 2008-07-25 15:28:23 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.


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