[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: All installs, and then all erases...

On Thu, Jun 05, 2003 at 05:15:43PM -0400, James Olin Oden wrote:
> Personally, I think that the current architecture is fine.  Disk space 
> these days is pretty cheap.  The issue that Jeff mentions about all the 
> dependencies being in place at the time you run the erases is far more
> beneficial that the space savings.

In general, that's true.

In some specific cases, saying "disk space these days is pretty cheap"
is like saying "assume a can opener":

+ IME, computers without much disk space probably don't have
  hot-swappable disks either. That means downtime.

+ The new disk might not be as reliable as the old one, if you're
  unlucky -- that means more downtime. (Multiply that by the number of
  times the *new* new disk fails again and has to be replaced again!)

+ Some disks and some motherboards/BIOSes/chipsets just don't get along.
  I've seen cases where a computer simply refuses to boot off certain
  models of IBM drives, or freezes when some particular models of Western
  Digital drives are encountered in the BIOS IDE drive scan, or ...

+ The new controller card for your new drive might be incompatible with
  your motherboard's PCI bridge, thereby causing silent and intermittent
  data corruption. Or there may be an incompatibility between the
  motherboard BIOS and your controller card's firmware, so the system
  freezes up.

+ SCSI Voodoo. Need I say more?

+ The computer's case may not provide adequate ventilation for a higher
  capacity disk with the same performance as the old disk, and it may be
  physically impossible to add more ventilation to the case (especially
  with laptops).

These are not just theoretical concerns -- I have encountered all of
the above, and then some.

Disk space is cheap. Getting that disk space to work with the rest of
the computer sometimes isn't. (The above passage is not meant as an
attack on anyone, but rather as an explanation of why "disk space is
cheap" isn't the whole story and why some of us still have to care about
these things.)

> Also, breaking things up into multiple
> transactions could work, but its been my experience that everything runs 
> smoother if you can get all your rpm's installed as one transaction.  

That's my experience too, but it's often less risky to try installing
smaller groups of packages than to try upgrading hardware.

> In the case of disk space constrains this would mean that up2date or yum
> would have to calculate the disk space requirements ahead of time rather
> than let rpm do it for it.  Course, I suppose such scripts could use 
> librpm internal routines for checking such things.
> Just my 2cents...james 

I've been thinking about writing a wrapper script that tries to apply
everything with a single up2date invocation, and tries again with
smaller sets of packages if up2date fails. This seems like it would be
a dirty hack, which is why I haven't done it yet, but the more I think
about it the more I wonder if the alternatives would really be any
cleaner from a design standpoint...

-Barry K. Nathan <barryn@pobox.com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []