OK Here's the official word from Digital, sent to me by Thomas Leitner. Thanks!
I *think* this explains what I saw. The short answer is that "due to historical
reasons", ie disks used to be expensive, there is a tendancy to make the
root partition just barely big enough. I talked to Tom Blinn and he
suggests making root 96 Megabytes (or more if you want). This, of course,
requires a custom install.
When I ran short of space, I didn't have a lot of extra stuff to delete, so
I moved out genvmunix. Well, according to the attached memo, that did me
no good, since the install process calculates the space needed for a new
genvmunix in it want list. I also moved out a bunch of binaries in sbin
which, while not used *by* install, are reinstalled during the process. Again,
I made space, but did not *gain* space since DU needs to replace that stuff.
It sort of makes sense now, but at the time that did not occur to me.
Thanks to all who replied to this issue, and DEC, if your listening...
Please make the default root partition big enough so we don't have
to go through this. Disk is now very cheap. Wasting 20 or 30 megs is nothing
compared to the cost of my time spending several hours trying to get install
to proceed.
-Burch-
-------------------------------------------------------------------------------
Forwarded message:
> Date: Fri, 22 Nov 1996 08:31:12 +0100 (MET)
> From: Thomas Leitner <tom_at_finwds01.tu-graz.ac.at>
> To: Burch Seymour RTPS <bseymour_at_encore.com>
> Subject: Re: Upgrading from DU3.2G to DU4.0A.......
> Burch,
>
> On Thu, 21 Nov 1996, Burch Seymour RTPS wrote:
>
> > Here's a question for the brave souls who have upgraded DU rather than
> > doing a full install.
>
> [...]
>
> As far as I can remember, this is a known problem and there is sort of
> a workaround described in a text by a DEC employee. The text appeared
> in the comp.unix.osf.osf1 newsgroup some month ago.
>
> Here is the text and it hope it clarifies the problem:
>
> ------------------------------------------------------------------------
> Important Information Regarding Digital UNIX
> Update Installation Disk Space Problems
>
>
> A number of users have experienced problems recovering ample disk
> space after an update installation has aborted due to insufficient
> space. The following is an example of a typical problem encountered
> during an update:
>
> 1) The update installation exits and indicates that additional space is
> needed in a particular file system (root, /usr, and/or /var) to perform
> the update.
>
> 2) The user deletes or moves files from the affected file system
> and/or removes subsets.
>
> 3) The user initiates another update attempt.
>
> 4) The update installation aborts again because of lack of space, even
> though the user believes that the space requested during the first
> attempt has been recovered.
>
> There may be several reasons for this problem:
>
> o Some users are not following the proper method for removing
> system files to recover disk space, as described below.
>
> o A bug has been identified in the update installation disk
> space calculation for AdvFS file systems. See "AdvFS Disk Space
> Calculation Bug" below.
>
> o Deletion of small files from an AdvFS file system may not
> immediately free additional space. See "Additional AdvFS
> Considerations" below.
>
>
> How to Properly Free Disk Space for an Update Installation
> ----------------------------------------------------------
>
> The proper methods for freeing disk space are as follows:
>
> 1) Remove any non-critical optional subsets using 'setld -d'.
> Deleting or moving individual system files without using the
> 'setld' command will not yield the additional space needed to
> continue.
>
> Refer to the appropriate appendix of the Installation Guide
> containing the subset size information that corresponds to the
> version of Digital UNIX that you have currently installed to
> help you decide which subsets to remove.
>
> 2) Remove any non-critical user-added files which are not part of
> the base or layered product inventory. Typical large space
> consumers are left over core files and kernels that are no
> longer required.
>
> 3) For those who have previously performed Digital UNIX update
> installations, left over obsolete system files, .PreUPD files,
> and .PreMRG files can use significant amounts of file system
> space. Use the 'updadmin' utility to first back-up then delete
> these files.
>
> 4) For AdvFS filesystems, it is possible to save approximately
> 3MB in root by building a mandatory only kernel (the default)
> rather than an interactive kernel (i.e. do not specify the "-i"
> flag to installupdate). Note that you must specify the "-i"
> flag if there are optional kernel selections that your system
> depends upon that cannot be satisfied by a mandatory kernel.
>
> Why doesn't deleting individual system files free space for the update?
> -----------------------------------------------------------------------
>
> Deleting files which are part of installed base or layered
> product subsets will not produce additional free space because the
> update installation takes into account that these old files will be
> replaced by new versions. The disk space calculation determines how
> much additional space is needed to replace an old version of a file
> with its new version.
>
> If the old version of a file is removed without removing the
> entire subset in which it resides, the update installation will still
> put the new version on the system. In this situation the full size
> of the new file will be allocated instead of the difference between the
> size of the original and new versions.
>
> For example, if /genvmunix was 7MB and a new version of
> /genvmunix was 8MB, update would need to reserve 1MB of free space
> for the new version. If /genvmunix was deleted before the update,
> the disk space calculation would then reserve the full 8MB for the
> new file. So although 7MB was freed before the update, 7MB more
> would be reserved during the update, which would result in no
> difference in the amount of additional space needed to continue the
> update.
>
>
> AdvFS Disk Space Calculation Bug
> --------------------------------
>
> There is currently a known problem with the update space
> calculation procedure for AdvFS file systems. The bug may cause the
> update installation to report an amount of 'additional space needed'
> that is smaller than what is actually necessary. Therefore subsequent
> update attempts may still request additional space even after the amount
> originally requested has been freed. This bug has been fixed for future
> releases.
>
>
> Additional AdvFS File System Considerations
> -------------------------------------------
>
> When removing small files (less than 8K) from an AdvFS file
> system, additional free space may not be made available to the file
> system immediately. After the total amount of space consumed by these
> deleted files reaches a threshold value, all of the space is made
> available in one large block. This explains why deletion of several
> small files may not increase the available block count (as shown by
> "df", for example). In this case the user must continue to delete
> non-system user-added files until there is an adequate increase in the
> available block count to allow the update installation to continue.
>
> - Brad Musolff
> User Environment & Standards Group
> Digital Equipment Corporation
>
> --------------------------------------------------------------------------
> T o m L e i t n e r Dept. of Communications
> Graz University of Technology,
> e-mail : tom_at_finwds01.tu-graz.ac.at Inffeldgasse 12
> Phone : +43-316-873-7455 A-8010 Graz / Austria / Europe
> Fax : +43-316-463-697
> Home page : http://wiis.tu-graz.ac.at/people/tom.html
> PGP public key on : ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send
> mail with subject "get Thomas Leitner" to pgp-public-keys_at_keys.pgp.net
> --------------------------------------------------------------------------
>
>
--
This message from, Encore Computer Corporation MS/712
Burch Seymour 6901 W Sunrise Boulevard
Senior Consultant Fort Lauderdale, Fl 33313
email: bseymour_at_encore.com Telephone: (305) 797-5627
Received on Fri Nov 22 1996 - 15:08:06 NZDT