Bug 73055 - RPM install fails if large NFS volume is mounted
RPM install fails if large NFS volume is mounted
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Depends On:
  Show dependency treegraph
Reported: 2002-08-30 03:49 EDT by Pekka Pessi
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-30 13:51:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
output of rpm -ivv (12.80 KB, text/plain)
2002-08-30 12:29 EDT, Pekka Pessi
no flags Details
strace output of rpm -i redhat-lsb-... (5.41 MB, text/plain)
2002-08-30 12:32 EDT, Pekka Pessi
no flags Details

  None (edit)
Description Pekka Pessi 2002-08-30 03:49:22 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607

Description of problem:
When trying to install a RPM package while a large NFS disk  is mounted, the rpm
fails and complains about insufficient disk space on NFS disk.
The NFS disk has 1404 GB (1274 GB is free).

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

How reproducible:

Steps to Reproduce:
1. Mount a large NFS volume
2. Try to install any RPM package


Actual Results:  [root@agni ppessi]# rpm -i /tmp/sigcomp-devel-1.0-1.i386.rpm 
installing package sigcomp-devel-1.0-1 needs 845Mb on the /project/iptel filesystem
[root@agni ppessi]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda5              7887760   5234592   2252492  70% /
/dev/hda7              9770224   9003564    270348  98% /local
none                    321564         0    321564   0% /dev/shm
                     1404930088 130727784 1274202304  10% /project/iptel
[root@agni ppessi]# rpm -q rpm
[root@agni ppessi]# umount /project/iptel  
[root@agni ppessi]# rpm -i /tmp/sigcomp-devel-1.0-1.i386.rpm 
[root@agni ppessi]# 

Expected Results:  [root@agni ppessi]# rpm -i /tmp/sigcomp-devel-1.0-1.i386.rpm 
[root@agni ppessi]# 

Additional info:
Comment 1 Jeff Johnson 2002-08-30 04:56:56 EDT
Can you supply info about how rpm failed?

For example, appending the output of of "rpm -ivv"
as a bugzilla attachment would help.
Comment 2 Pekka Pessi 2002-08-30 12:29:17 EDT
Created attachment 73984 [details]
output of rpm -ivv
Comment 3 Pekka Pessi 2002-08-30 12:32:08 EDT
Created attachment 73985 [details]
strace output of rpm -i redhat-lsb-...
Comment 4 Jeff Johnson 2002-08-30 12:49:25 EDT
OK, the offending line is

statfs("/project/iptel", {f_type="NFS_SUPER_MAGIC", f_bsize=512,
f_blocks=2807363208, f_bfree=2545068192, f_files=18788197, f_ffree=16520342,
f_namelen=255}) = 0
stat64("/project/iptel", {st_mode=S_IFDIR|S_ISGID|0771, st_size=8192, ...}) = 0

Hmmm, are you specifying a blocksize of 512 when mounting? If so, you might
try increasing the blocksize to something largere. OTOH, NFS may always
be reporting f_bsize == 512, I haven't looked in quite awhile.

Checking ... yup, an NFS mount of mine is reporting

statfs("/mnt/redhat", {f_type="NFS_SUPER_MAGIC", f_bsize=4096,
f_blocks=83225243, f_bfree=15936499, f_files=0, f_ffree=0, f_namelen=255}) = 0

So increase your blocksize to reduce the overflow is the workaround
until I get a chance to refigger statfs, statvfs, and all the other
myriad ways that unix has to report back no. of available blocks.

Comment 5 Pekka Pessi 2002-08-30 13:51:52 EDT
Thanks. I'll try to get someone to fiddle with file servers; I gather it is not
possible to change block size from client side?
Comment 6 Jeff Johnson 2002-08-31 14:09:58 EDT
I believe (I asked someone) it's possible to change
the block size on the client, see the NFS mount options,
but a careful experiment, say, using strace on rpm,
is advised.

Meanwhile I'm gonne defer the final solution, fixing rpm,
until I get a chance to figger the portability issues on non-linux

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