Bug 73055

Summary: RPM install fails if large NFS volume is mounted
Product: [Retired] Red Hat Linux Reporter: Pekka Pessi <pekka.pessi>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-08-30 17:51:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
output of rpm -ivv
none
strace output of rpm -i redhat-lsb-... none

Description Pekka Pessi 2002-08-30 07:49:22 UTC
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:
Always

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
uxsandbox:/sandbox/iptel
                     1404930088 130727784 1274202304  10% /project/iptel
[root@agni ppessi]# rpm -q rpm
rpm-4.0.4-7x.18
[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 08:56:56 UTC
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 16:29:17 UTC
Created attachment 73984 [details]
output of rpm -ivv

Comment 3 Pekka Pessi 2002-08-30 16:32:08 UTC
Created attachment 73985 [details]
strace output of rpm -i redhat-lsb-...

Comment 4 Jeff Johnson 2002-08-30 16:49:25 UTC
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 17:51:52 UTC
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 18:09:58 UTC
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