Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!inria!axis!philip
From: philip@axis.UUCP (Philip Peake)
Newsgroups: comp.unix.wizards
Subject: Re: truncating root directory of a file system
Message-ID: <776@axis.UUCP>
Date: Sun, 7-Dec-86 06:24:37 EST
Article-I.D.: axis.776
Posted: Sun Dec  7 06:24:37 1986
Date-Received: Mon, 8-Dec-86 02:11:49 EST
References: <511@cdx39.UUCP>
Reply-To: philip@axis.UUCP (Philip Peake)
Organization: Axis Digital, 135 rue d'Aguesseau, Boulogne, 92100, FRANCE
Lines: 38
Keywords: / /usr /usr/lib truncation

In article <511@cdx39.UUCP> jc@cdx39.UUCP writes:
>Well, there's a case where this doesn't work too well. 
>This is the root directory of a file system. 
>
>This is a root directory of a file system.  There are 
>about 75 directories under this one, so it only needs 
>to be about 1200 bytes in size.  Is there a way to shrink
>it down somewhat?
>
>On systems with the ftrunc() system call, there is an
>obvious solution.  Our SYS5 doesn't have ftrunc(), so
>there seems to be no way to do the job.  Or is there?

You can do it. It is a little complicated.

Basically, you move all of the entries in the directory to the first few slots.
You can do this by carefull use of link and rm.

If you really want to, you can do it with a standalone fsdb - just be
certain that you get it right !

Having done this, unless you really want to recover the block or two
of disc holding null entries, just leave things alone.
The only time the extra space will be scanned is when anyone gives a
full pathname which contains a non-existent first component - this should
be rare enough to ignore.

if you want the blocks back, use a standalone fsdb to remove the references
to the unused blocks at the end of the root directory inode list (set them
to zero).

Run fsck on the root to recover the blocks into the free list, and there
you are.

The best advice I can give it not to get into this situation in the
first place !

Philip