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:
Can you supply info about how rpm failed? For example, appending the output of of "rpm -ivv" as a bugzilla attachment would help.
Created attachment 73984 [details] output of rpm -ivv
Created attachment 73985 [details] strace output of rpm -i redhat-lsb-...
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.
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?
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