Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!uwvax!uwslh!dem
From: dem@uwslh.UUCP (David E. Miran)
Newsgroups: comp.unix.wizards
Subject: Re: truncating root directory of a file system
Message-ID: <165@uwslh.UUCP>
Date: Tue, 9-Dec-86 09:55:31 EST
Article-I.D.: uwslh.165
Posted: Tue Dec  9 09:55:31 1986
Date-Received: Wed, 10-Dec-86 03:37:45 EST
References: <511@cdx39.UUCP> <2302@mtgzy.UUCP>
Organization: U of Wisconsin-Madison, State Hygiene Lab
Lines: 28

In article <511@cdx39.UUCP>, jc@cdx39.UUCP (John Chambers) writes:
> Hey, here's a good puzzle for a Unix file-system wizard.
> You know how some directories (like /usr/spool/uucp) can
> get really huge... The usual solution is to rebuild
> the directory - you rename it, create a new one in its
> place, and moving the contents from the old one to the new.
> 
> Well, there's a case where this doesn't work too well. 
> This is the root directory of a file system.
There is a very straightforeward solution to this problem, which
also cleans up other problems related to poor allocation of parts
of the disk unit.
1.  Do a full save of the unit to tape.
2.  Unmount the unit.
3.  Recreate a file system on the unit using newfs or mkfs.
4.  Do a full restore of the unit from tape.
5.  Do a full save again since all the creation dates change.
This is also a good time to check your average file size and perhaps
recreate the unit with a larger number of bytes per inode.
The Berkeley default is very conservative.  On our system we gain
several megabytes of useable space per 150 M partition by increasing
the number of bytes per inode.
-- 
David E. Miran         ...!{seismo,harvard,topaz,ihnp4}!uwvax!uwslh!dem
Wisconsin State Hygiene Lab    or    uwslh!dem@rsch.wisc.edu
University of Wisconsin          (608) 262-0019
465 Henry Mall
Madison, WI  53706