Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!news.cs.indiana.edu!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!gacvx2.gac.edu!scott From: scott@erick.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: Misc questions Message-ID: Date: 5 Mar 91 05:59:20 GMT References: Organization: Gustavus Adolphus College Lines: 58 Nntp-Posting-Host: erick.gac.edu In-reply-to: aberno@questor.wimsey.bc.ca's message of 5 Mar 91 00:12:58 GMTLines: 58 In article aberno@questor.wimsey.bc.ca (Anthony Berno) writes: 1) When you add the size of root (found by using the Inspector panel in the workspace) with the amount of free space on the disk, is it supposed to total the size of the disk? I am short by about 80 meg on a 660 meg disk. No, I don't have a partition, in fact I removed it when I got my computer by doing a build disk. The transcript from the build revealed that it should have 690 meg, and when I opened up the computer to fix a little rattle, the sticker on the disk said it was 760 meg! Does anyone else have this problem with missing disk space? If you wouldn't mind, please do the above calculation and tell me what you get. I'm curious if this is normal - I suspect it is - but it bothers me to have an amount of space equal to 4 of the hard drives on my old Mac gone missing. A big culprit would be the version of du (or the du-like functionality) provided by the Workspace Inspector panel. The default du(1) utility provided gives the disk usage in bytes. This is misleading because few files require an integral number of blocks and fragments - most leave some free at the end of their frags. Thus, on average, if the number of files in the system is n, the amount of data "lost" to the space at the end of fragments is n*frag_size/2. Of course, that's a simplistic answer. Most executable files, for instance, use a multiple of 8k of space, and thus require a whole number of fragments (actually blocks). On the other hand, large files don't use fragments for the last couple k, and thus suffer larger average data "losses". Any way you put it, though, the more files you have, the more space is lost to this phenomonon. Anyhow, a solution to this particular problem is to grab the GNU fileutil's version of du. It count's the size in real space used, as in space allocated to the file (thus counting some unused space, too). This should come closer to the real value. Another place where data can be lost is due to the reserved blocks on a disk which are reserved to help prevent fragmentation. BSD FFS uses a weird and wonderful (with the emphasis on wonderful) system to keep files from being spread across multiple cylinder groups, and more importantly, to keep one file from forcing others to be spread across multiple cylinders. To make this work well, from 5 to 10% of the space on the file system is reserved. The actual amount depends on whether it was optimized for space or speed (that changes the way things work). Lastly, there might be bad blocks and blocks used to replace them counted in the disk's label, and those can't be used for regular storage (well, it would sort of defeat the purpose, if they were). Anyhow, more than likely all of your disk is there, somewhere . . . Later, -- scott hess scott@gac.edu Independent NeXT Developer GAC Undergrad "Tried anarchy, once. Found it had too many constraints . . ." "I smoke the nose Lucifer . . . Bannana, banna."