|
|
Looks like HFS+ is fixed-block size
From reading Apple's developer page on HFS+, it looks to me like HFS+ is fixed-block, it's simply more efficient than HFS because there are more blocks available to spread over the whole disk (32-bits worth instead of 16):
HFS divides the total space on a volume into equal-sized pieces called allocation blocks. It uses 16-bit fields to identify a particular allocation block, so there must be less than 216 (65,536) allocation blocks on an HFS volume. The size of an allocation block is typically the smallest multiple of 512 such that there are less than 65,536 allocation blocks on the volume (i.e., the volume size divided by 65,535, rounded up to a multiple of 512). Any non-empty fork must occupy an integral number of allocation blocks. This means that the amount of space occupied by a fork is rounded up to a multiple of the allocation block size. As volumes (and therefore allocation blocks) get bigger, the amount of allocated but unused space increases. HFS Plus uses 32-bit values to identify allocation blocks. This allows up to 2 32 (4,294,967,296) allocation blocks on a volume. More allocation blocks means a smaller allocation block size, especially on volumes of 1 GB or larger, which in turn means less average wasted space (the fraction of an allocation block at the end of a fork, where the entire allocation block is not actually used). It also means you can have more files, since the available space can be more finely distributed among a larger number of files. This change is especially beneficial if the volume contains a large number of small files.However, that's just my reading of it. I don't claim to be an expert. They don't explicitly use the phrase, "fixed-block" anywhere that I can find. Anyone know for certain?
Looks like HFS+ is fixed-block size
I wrote Trash X. When I added file shredding features to it, I relied on "rm -P" to handle the task. This was an embarassing mistake. In short, "rm -P" does not reliably shred files on HFS+ volumes. In my tests, it only worked on HFS+ in situations where the file to be shredded was larger than the available free space. In all other cases with HFS+, "rm -P" merely deleted the file without overwriting it. It is interesting to note however that "rm -P" takes longer to execute than just "rm". I believe that on HFS+ disks, "rm -P" essentially deletes the old file and creates a new file on each pass and writes its data sequence into it, but that is just conjecture on my part. |
SearchFrom our Sponsor...Latest Mountain Lion HintsWhat's New:HintsNo new hintsComments last 2 daysNo new commentsLinks last 2 weeksNo recent new linksWhat's New in the Forums?
Hints by TopicNews from Macworld
From Our Sponsors |
|
Copyright © 2014 IDG Consumer & SMB (Privacy Policy) Contact Us All trademarks and copyrights on this page are owned by their respective owners. |
Visit other IDG sites: |
|
|
|
Created this page in 0.08 seconds |
|