Bug 438762 - gfs_tool: Cannot allocate memory
Summary: gfs_tool: Cannot allocate memory
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gfs-utils
Version: 5.2
Hardware: x86_64
OS: Linux
Target Milestone: rc
: ---
Assignee: Robert Peterson
QA Contact: GFS Bugs
URL: https://www.redhat.com/archives/linux...
Depends On: 435469
TreeView+ depends on / blocked
Reported: 2008-03-24 22:14 UTC by Robert Peterson
Modified: 2010-01-12 03:33 UTC (History)
1 user (show)

Clone Of:
Last Closed: 2009-01-20 20:32:57 UTC

Attachments (Terms of Use)
Patch to fix the problem (702 bytes, patch)
2008-04-15 14:34 UTC, Robert Peterson
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:0059 normal SHIPPED_LIVE gfs-utils bug-fix update 2009-01-20 16:04:02 UTC

Description Robert Peterson 2008-03-24 22:14:48 UTC
+++ This bug was initially created as a clone of Bug #435469 +++
Cloned the bugzilla record so I can crosswrite the fix to RHEL5.3.

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.

-- Additional comment from rpeterso@redhat.com on 2008-02-29 11:29 EST --
Reassigning to me.  The "additional info" comments are mine from
linux-cluster mailing list.  Thanks, Robert.

-- Additional comment from rpeterso@redhat.com on 2008-03-24 14:04 EST --
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 1 Robert Peterson 2008-03-25 17:56:55 UTC
Requesting flags so I can get this into RHEL5.3.

Comment 2 Robert Peterson 2008-04-15 14:34:49 UTC
Created attachment 302462 [details]
Patch to fix the problem

Comment 3 Robert Peterson 2008-04-15 14:43:19 UTC
I pushed this fix to the RHEL5, master, and STABLE2 branches of the
cluster git tree.  Testing was done on roth-01.  Changing status to

Comment 6 errata-xmlrpc 2009-01-20 20:32:57 UTC
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 therefore 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.