On Tuesday 09 July 2002 07:19 pm, Rod Taylor wrote:
> On Tue, 2002-07-09 at 19:09, Lamar Owen wrote:
> > And what if you have enough disk space to do the dump, but then that
> > causes the OS upgrade to abort because there wasn't enough space left to
> > finish upgrading (larger packages, perhaps)? The system's hosed, and
> > it's our fault.
> What normally happens when you have low amounts of free diskspace and
> attempt to upgrade the system?
Anaconda calculates (internally -- it's a Python program) the space required
by the upgrade and won't let you proceed if you don't have enough space as
reported by the RPM headers. It's impossible to know ahead of time how much
space will be required by an ASCII dump of the PostgreSQL database, and thus
it cannot be taken into account by that algorithm.
As to failing cleanly, work is underway to allow RPM to rollback entire OS
upgrades. But again the disk space requirement shoots through the ceiling if
you do this. Already RPM can rollback the transaction being done on the RPM
database (it's a db3 database system), but rolling back the filesystem is a
little different.
But anaconda (which doesn't use the command line RPM anymore, it uses librpm
to do its own RPM processing) checks beforehand how much space is needed and
won't let you overspend disk space during the system upgrade.
The command-line RPM will also do this, and won't let you upgrade RPM's if
there's not enough disk space, as calculated by reading the RPM header, which
has the amount of space the uncompressed package takes (calculated as part of
the RPM build process).
But if you throw in an unknown increase in space that anaconda/rpm cannot
grok, then you cause a situation.
Can the ports system take into account the space required for a dumpfile?? :-)
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11