Imi permit un citat dintr-o lucrare referitoare la sisteme de fisiere ....
Daca aveti rabdare, parcurgeti-l. E interesant ... MAI ALES ULTIMA FRAZA !!!
Built-in Measures in Mac OS X Against Fragmentation
As stated earlier, the primary allocation method in HFS+ is extent-based, which helps in contiguity. Moreover, HFS+ uses delayed allocation: rather than allocating blocks as a file is written in memory, the filesystem can reserve (or loan) blocks, delaying actual allocation until the buffer cache is flushed to disk. Thus, several small allocations can be combined into larger, possibly contiguous, allocations.
While Apple does not provide a defragmentation tool, they introduced a few HFS+ optimizations in “Panther”, two of which play important roles in countering (even undoing) the fragmentation of files that are below a certain size, and are frequently accessed.
On-the-fly Defragmentation
When a file is opened on an HFS+ volume, the following conditions are tested:
If the file is less than 20 MB in size
If the file is not already busy
If the file is not read-only
If the file has more than eight extents
If the system has been up for at least three minutes
If all of the above conditions are satisfied, the file is relocated—it is defragmented on-the-fly.
Hot File Clustering
This optimization is currently available only on boot volumes. Hot File Clustering is a multi-staged clustering scheme that records “hot” files (except journal files, and ideally quota files) on a volume, and moves them to the “hot space” on the volume (0.5% of the total filesystem size located at the end of the default metadata zone, which itself is at the start of the volume). The files are also defragmented. The various stages in this scheme are DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION, and ADOPTION. At most 5000 files, and only files less than 10 MB in size are “adopted” under this scheme.
You can use hfsdebug to explore the working of Hot File Clustering.
A defragmenting tool should not move a file into the hot file area, nor should it move a file out of the hot file area. Doing so might degrade performance!
Poor Man’s Defragmentation
As we have seen, an HFS+ volume seems to resist fragmentation rather well on Mac OS X 10.3.x, and I don’t envision fragmentation to be a problem bad enough to require proactive remedies (such as a defragmenting tool).
hfsdebug can list all fragmented files (forks) on a volume, and can also sort them based on the number of extents each has. Although it would depend on a number of factors (such as a file’s size, free space on the volume, and so on), if you simply moved (as a backup) a file with a highly fragmented fork to a new name, and copied it to the original name, the new copy might have lesser, or even no fragmentation, which you may check using hfsdebug. Please understand that I do not recommend that you do this! If you are really bent upon defragmenting your HFS+ volume, a more appropriate way would be to write your own defragmentation tool. The Carbon File Manager has functions that let you allocate contiguous space on a volume.
Moving a file to a new name does not change its Catalog Node ID (CNID), and copying it back to the original name will result in the copy having a different CNID.
Conclusion
Defragmentation on HFS+ volumes should not be necessary at all, or worthwhile, in most cases, because the system seems to do a very good job of avoiding/countering fragmentation.
It is risky to defragment anyway: What if there’s a power glitch? What if the system crashes? What if the defragmenting tool has a bug? What if you inadvertently reboot? In some cases, you could make the situation worse by defragmenting.
