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 ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster