jc@cdx39.UUCP (John Chambers) (12/05/86)
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, and then, even if most of the files go
away, the directory stays large, giving poor performance
for some applications. 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. If you
do the usual, the new directory isn't the first one
in the inode table, and all hell breaks loose when
you try to delete the old one. What happens when you
mount a file system whose root directory has been rm'd,
you just wouldn't believe!
Typical directories are / (of course), /usr, /usr/lib,
and occasionally others for various 'user' disks. We
have a machine on which, for reasons too complicated to
explain here, has the following:
drwxrwxr-x55 root sys 18880 Nov 24 17:17 /user
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?
--
John M Chambers Phone: 617/364-2000x7304
Email: ...{adelie,harvax,inmet,mcsbos,mit-eddie,mot[bos],rclex}!cdx39!{jc,news,root,usenet,uucp}
Smail: Codex Corporation; Mailstop C1-30; 20 Cabot Blvd; Mansfield MA 02048-1193philip@axis.UUCP (Philip Peake) (12/07/86)
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
ecl@mtgzy.UUCP (12/08/86)
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. How about: 1) Unmount all file systems. 2) Make another copy of root on some spare slice (volcopy). 3) Boot off the spare slice. 4) Mount the old root as /mnt. 5) Cpio /mnt to a directory Nmnt (you may need another spare slice). 6) rm -fr /mnt and cpio Nmnt back to /mnt. 7) Unmount /mnt. 8) Reboot off the original slice. If slices are tight, you could probably do #5 and #6 using tape. (This sounds like it should work, but I make no promises.) Evelyn C. Leeper (201) 957-2070 UUCP: ihnp4!mtgzy!ecl ARPA: mtgzy!ecl@rutgers.rutgers.edu In this world you must be oh so smart or oh so pleasant. --Elwood P. Dowd (HARVEY)
whp@cbnap.UUCP (Wayne H. Pollock) (12/09/86)
In article <2302@mtgzy.UUCP> ecl@mtgzy.UUCP writes: >How about: >[ eight steps using two spare slices or tape] > > Evelyn C. Leeper Hmm, this is too complicated! How 'bout: 1) volcopy root to spare slice 2) boot from spare slice 3) mkfs /dev/rdsk/0s0 (ie original root) 4) mount /dev/dsk/0s0 /mnt 5) find /* -print |cpio -pdml /mnt # where /* doesn't include /mnt! Wayne H. Pollock, UUCP: ...{ihnp4,cbatt}!cbnap!whp "The opinions expressed above are ficticious. Any resemblance to the opinions of persons living or dead is purely coincidental." -- Wayne H. Pollock, Your Friendly Neighborhood System Administrator The Shell Answer Man UUCP: ...{ihnp4,cbatt}!cbnap!whp DELPHI: WHP GEnie: W.POLLOCK Wayne H. Pollock, ...!cbnap!whp CB x4575 Room: 3S-235 6200 East Broad Street, Columbus Ohio 43213 Room: 3S-235 "The opinions expressed above are ficticious. Any resemblance to the opinions of persons living or dead is purely coincidental."
dem@uwslh.UUCP (David E. Miran) (12/09/86)
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
richl@penguin.UUCP (12/09/86)
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, and then, even if most of the files go > away, the directory stays large, giving poor performance > for some applications. I know this doesn't solve it for many sites, but I should add that 4.3 will truncate directories for you automatically. Each time an entry is added to a directory, excess space is removed. So if a directory grows huge, and you then remove everything from it, it is still huge. But when you next add something, the directory will shrink. Rick Lindsley