rpm and disk space checking
Kim Woods
If there is insufficient space to install a package will rpm state this and
refuse to install the package
or try to install it and back it out when it has space problems??
I want to put a .tar file in an rpm package and untar it in the
post-install script, is there a way to tell
rpm that the amount of space this package requires is actually more that
the size of the files it is
installing and get it to report the space problem rather than inventing my
own pre-install script to do
my own space calculations.
Any help or pointers on this would be appreciated
Kim.
_______________________________________________
Rpm-list mailing list
Rpm-...@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list
Jeff Johnson
> Can anyone tell me how rpm copes with lack of disk space??
> If there is insufficient space to install a package will rpm state this and
> refuse to install the package
> or try to install it and back it out when it has space problems??
>
rpm computes a file resolution for all package files, checks that there
is sufficient disk space at the same time. So, no package in a transaction
is unpacked unless here is enough disk space for all pacakes in the transaction.
> I want to put a .tar file in an rpm package and untar it in the
> post-install script, is there a way to tell
> rpm that the amount of space this package requires is actually more that
> the size of the files it is
> installing and get it to report the space problem rather than inventing my
> own pre-install script to do
> my own space calculations.
If you insist on putting a tarball into a package, rpm will check that
there's enough disk space for the tarball itself. Insuring that there's
enough space to unpack the tarball in %post is up to you.
If you untar before packaging, and put the files from the tarball
into the package, then rpm will check that there's enough room for
all the files, and will also do the unpacking.
73 de Jeff
--
Jeff Johnson ARS N3NPQ
j...@redhat.com (j...@jbj.org)
Chapel Hill, NC
Paul Jackson
> rpm computes a file resolution for all package files, checks
> that there is sufficient disk space at the same time. So,
> no package in a transaction is unpacked unless here is enough
> disk space for all pacakes in the transaction.
Except (last I looked) for fat/vfat file systems. Here rpm used
to check, but perhaps because the statfs/statvfs call doesn't
return the number of inodes availble on fat file systems, when
the inode avail check was added, it had to be skipped for fat
file systems (any iavail <= 0 case), and as a perhaps unintended
consequence, the free disk block check was skipped for fat/vfat
as well. We noticed this in particular on the ia64 /boot/efi
(vfat) file system, installing kernels.
Or at least that was my cursory reading of the code ... I'm
confident that Jeff will correct me if I'm confused.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
Jeff Johnson
> On Thu, 25 Apr 2002, Jeff Johnson wrote:
> > that there is sufficient disk space at the same time. So,
> > no package in a transaction is unpacked unless here is enough
> > disk space for all pacakes in the transaction.
>
> to check, but perhaps because the statfs/statvfs call doesn't
> return the number of inodes availble on fat file systems, when
> the inode avail check was added, it had to be skipped for fat
> file systems (any iavail <= 0 case), and as a perhaps unintended
> consequence, the free disk block check was skipped for fat/vfat
> as well. We noticed this in particular on the ia64 /boot/efi
> (vfat) file system, installing kernels.
>
> Or at least that was my cursory reading of the code ... I'm
> confident that Jeff will correct me if I'm confused.
Yup, fat/vfat and some iother file systems don't report their
available blocks correctly through statf/statvfs/whatever.
Ditto available inodes.
Paul Jackson
> Yup, fat/vfat and some iother file systems don't report their
> available blocks correctly through statf/statvfs/whatever.
Partially wrong. At least in the case of the ia64 vfat
file system, the available blocks _are_ ok, so far as I
can tell, just not the available inodes.
I'd recommend you change the code to not skip the space
check just because the inode check sees a bad iavail.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
_______________________________________________
Jeff Johnson
> On Thu, 25 Apr 2002, Jeff Johnson wrote:
> > Yup, fat/vfat and some iother file systems don't report their
> > available blocks correctly through statf/statvfs/whatever.
>
> file system, the available blocks _are_ ok, so far as I
> can tell, just not the available inodes.
>
> I'd recommend you change the code to not skip the space
> check just because the inode check sees a bad iavail.
>
<shrug>
Chasing per-platform, per-device, per-filesystem-type, per-uglix-syscall, ...
fuinctionality is madness, particularly for imaginary package installs
on removable media mountpoints.
Jeff Johnson
> >
> > <shrug>
> > Chasing per-platform, per-device, per-filesystem-type, per-uglix-syscall, ...
> > fuinctionality is madness, particularly for imaginary package installs
> > on removable media mountpoints.
>
> partition makes sense on certain older machines where multiple
> operating systems need to be involved. If this was possible, it
> would have saved me 4-5 hours fixing a problem on a rather crufty
> old box I had to set up a couple weeks ago!
>
Patches cheerfully accepted, bugzilla preferred.
Max TenEyck Woodbury
>
> On Thu, Apr 25, 2002 at 12:31:29PM -0700, Paul Jackson wrote:
> > On Thu, 25 Apr 2002, Jeff Johnson wrote:
> > > Yup, fat/vfat and some iother file systems don't report their
> > > available blocks correctly through statf/statvfs/whatever.
> >
> > file system, the available blocks _are_ ok, so far as I
> > can tell, just not the available inodes.
> >
> > I'd recommend you change the code to not skip the space
> > check just because the inode check sees a bad iavail.
> >
>
> Chasing per-platform, per-device, per-filesystem-type, per-uglix-syscall, ...
> fuinctionality is madness, particularly for imaginary package installs
> on removable media mountpoints.
Argh! PLEASE do it right if you can. In particular, a vfat boot
partition makes sense on certain older machines where multiple
operating systems need to be involved. If this was possible, it
would have saved me 4-5 hours fixing a problem on a rather crufty
old box I had to set up a couple weeks ago!
Paul Jackson
> Chasing per-platform, per-device, per-filesystem-type, per-uglix-syscall, ...
> fuinctionality is madness, particularly for imaginary package installs
> on removable media mountpoints.
That's not what I'm asking. I'm just suggesting that you don't
assume that just because the iavail is bad means that the bavail
is bad.
To wit, change from:
for (i = 0; i < ts->filesystemCount; i++) {
dip = ts->di + i;
if (dip->iavail <= 0)
continue;
if (adj_fs_blocks(dip->bneeded) > dip->bavail)
psAppend(ts->probs, RPMPROB_DISKSPACE, fi->ap,
ts->filesystems[i], NULL, NULL,
(adj_fs_blocks(dip->bneeded) - dip->bavail) * dip->bsize);
if (adj_fs_blocks(dip->ineeded) > dip->iavail)
psAppend(ts->probs, RPMPROB_DISKNODES, fi->ap,
ts->filesystems[i], NULL, NULL,
(adj_fs_blocks(dip->ineeded) - dip->iavail));
}
to:
for (i = 0; i < ts->filesystemCount; i++) {
dip = ts->di + i;
if (dip->bavail > 0 &&
adj_fs_blocks(dip->bneeded) > dip->bavail)
psAppend(ts->probs, RPMPROB_DISKSPACE, fi->ap,
ts->filesystems[i], NULL, NULL,
(adj_fs_blocks(dip->bneeded) - dip->bavail) * dip->bsize);
if (dip->iavail > 0 &&
adj_fs_blocks(dip->ineeded) > dip->iavail)
psAppend(ts->probs, RPMPROB_DISKNODES, fi->ap,
ts->filesystems[i], NULL, NULL,
(adj_fs_blocks(dip->ineeded) - dip->iavail));
}
Simple - no?
And it ain't imaginary. Pretty much every ia64 system install
from now until hell freezes over will involve installing kernels
into /boot/efi, a vfat file system (and not routinely removable
either -- I don't know where you got that idea).
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <p...@sgi.com> 1.650.933.1373
_______________________________________________