Re: Disk Usage Incorrect
Re: Disk Usage Incorrect
- Subject: Re: Disk Usage Incorrect
- From: Matt Deatherage <email@hidden>
- Date: Thu, 13 Jan 2005 17:12:09 -0600
On 1/12/05 at 5:17 PM, Craig E. Ward <email@hidden> wrote:
> If a resource fork is also allocated for a 1 byte file, wouldn't that
> explain the extra 4 blocks?
Unless I am mistaken, Mac OS X's HFS Plus implementation does not allocate any blocks to a fork until that fork has a non-zero length. If you have a copy of Norton Disk Editor X, you can look at the HFS Plus directory entry for any file and see how many blocks are allocated to each fork.
On 1/12/05 at 4:34 PM, Jerry Pendergraft <email@hidden> wrote:
> On the point of comparing file size to allocated size I did a quick and
> dirty perl script to stat files and find out what allocated size was for
> various file sizes. Got a big surprise when this reported more than a
> fraction of a block of waste for larger files. And the the minimum
> allocation seems to be 8 blocks even for the 1 byte file.
On most HFS Plus disks, the allocation block size is 4KB, as noted; since stat uses 512-byte blocks (as also noted by Clark Cox), it will *usually* tell you that there's more than one 512-byte block "wasted" at the end of the file. Presuming a linear distribution of file sizes across a disk, each file wastes, on average, half the allocation block size in its last block, or 2KB. Since you say the disk holds 860,137 files, you could expect to see about 1.7GB of space that's allocated but not used within any file's logical EOF. You report 58GB missing, and that's way too much.
In fact, it's outside the possible bounds for a normal HFS Plus disk. The most any file can waste is the size of a single allocation block minus one byte, and on a standard HFS Plus disk, that's 4KB-1 byte, or 4095 bytes. Multiply that times 860,137 files and you come up with about 3.5GB of "wasted" space - only 6% the figure you report.
So what could be happening? You say the system's disk repair framework (used in both fsck and Disk Utility) says nothing's wrong with the disk, so that's out.
You might have a volume with larger allocation blocks, but that's easy enough to determine:
echo "" > testfile.txt
and look at it in the Finder with "Get Info." The "(1 byte)" is the logical EOF, the other size number is the size of one allocation block on your disk. I'll bet it's 4KB, though. (It's possible to create HFS Plus disks with allocation blocks as small as 512 bytes, but Mac OS X's file system code is optimized for 4KB blocks, so it's generally not worth doing.)
If this is a test system that crashes a lot, you could have a lot of hidden wasted space in your test files. HFS Plus allocates by clumps for efficiency and to avoid fragmentation - opening a file and writing one byte to it allocates, by default, 16 allocation blocks (64KB) to the file. However, *closing* the file releases all the completely-unused allocation blocks back to the system. Terminating a process should do the same thing, but I can't vouch for it.
The Finder knows both the "physical size" (allocation blocks) and "size" (logical EOF) of every item, so in theory, you can write an AppleScript to find all files whose physical size - size > 4095 bytes to see what's going on. (Unfortunately, either of those can be "missing value" on folders or packages, and Finder doesn't really understand the concept of a packaged document, like a GarageBand song, so my quick attempts to do it all choked on such packages in ways I can't quickly work around.) Nonetheless, if you can do it in AppleScript, I imagine you can do it in shell scripting too.
I suspect that an earlier post is right too, though - utilities not run in admin mode may not be able to properly count files and folders to which you have no read access. You may have a lot more files than you think. You can always try launching a tool as root to see if it finds more reasonable numbers.
If the disk is not damaged, and you're missing 58GB of space, then either you can't see the files occupying it, or lots of files have space allocated beyond the last allocation block required to hold the logical EOF. If there are other explanations, I can't think of them.
--Matt
--
Matt Deatherage <email@hidden> <http://www.macjournals.com>
I read this list in digest mode; copy me privately for faster responses
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden