Check disc fragmentation in Terminal console?
- Thread starter d54321k
- Start date
bobw
The Late: SuperMacMod
Personally, I wouldn't use any version of Nortons.
If you must defrag, use TechTool pro.
From;
http://docs.info.apple.com/article.html?artnum=25668
You probably won't need to optimize at all if you use Mac OS X. Here's why:
Hard disk capacity is generally much greater now than a few years ago. With more free space available, the file system doesn't need to fill up every "nook and cranny." Mac OS Extended formatting (HFS Plus) avoids reusing space from deleted files as much as possible, to avoid prematurely filling small areas of recently-freed space.
Mac OS X 10.2 and later includes delayed allocation for Mac OS X Extended-formatted volumes. This allows a number of small allocations to be combined into a single large allocation in one area of the disk.
Fragmentation was often caused by continually appending data to existing files, especially with resource forks. With faster hard drives and better caching, as well as the new application packaging format, many applications simply rewrite the entire file each time. Mac OS X 10.3 Panther can also automatically defragment such slow-growing files. This process is sometimes known as "Hot-File-Adaptive-Clustering."
Aggressive read-ahead and write-behind caching means that minor fragmentation has less effect on perceived system performance.
For these reasons, there is little benefit to defragmenting.
Mac OS X systems have hundreds of thousands of small files, most of which are rarely accessed. Optimizing them is a major effort for very little practical gain. There is also the a chance that one of the files placed in the "hot band" for rapid reads during system startup might be moved during defragmentation, which would actually decrease performance.
If your disks are almost full, and you often modify or create large files, there's a chance they could be fragmented. In this case, you might benefit from defragmentation.
If you must defrag, use TechTool pro.
From;
http://docs.info.apple.com/article.html?artnum=25668
You probably won't need to optimize at all if you use Mac OS X. Here's why:
Hard disk capacity is generally much greater now than a few years ago. With more free space available, the file system doesn't need to fill up every "nook and cranny." Mac OS Extended formatting (HFS Plus) avoids reusing space from deleted files as much as possible, to avoid prematurely filling small areas of recently-freed space.
Mac OS X 10.2 and later includes delayed allocation for Mac OS X Extended-formatted volumes. This allows a number of small allocations to be combined into a single large allocation in one area of the disk.
Fragmentation was often caused by continually appending data to existing files, especially with resource forks. With faster hard drives and better caching, as well as the new application packaging format, many applications simply rewrite the entire file each time. Mac OS X 10.3 Panther can also automatically defragment such slow-growing files. This process is sometimes known as "Hot-File-Adaptive-Clustering."
Aggressive read-ahead and write-behind caching means that minor fragmentation has less effect on perceived system performance.
For these reasons, there is little benefit to defragmenting.
Mac OS X systems have hundreds of thousands of small files, most of which are rarely accessed. Optimizing them is a major effort for very little practical gain. There is also the a chance that one of the files placed in the "hot band" for rapid reads during system startup might be moved during defragmentation, which would actually decrease performance.
If your disks are almost full, and you often modify or create large files, there's a chance they could be fragmented. In this case, you might benefit from defragmentation.
chemistry_geek
Registered
FYI: Mac OS X DEFRAGMENTS itself (on an HFS+ volume)!
I found this information from
http://www.kernelthread.com/mac/osx/
from a Slashdot article here:
http://apple.slashdot.org/article.pl?sid=04/01/07/1615230&mode=thread&tid=179&tid=185&tid=190
The specific information is listed in "Mac OS X Filesystems" section.
Now, here's a direct quote of what I'm referring to:
HFS+ also has a few specific optimizations. When a file is opened on an HFS+ volume, the following conditions are tested:
* The file is less than 20 MB in size
* The file is not already busy
* The file is not read only
* The file is fragmented (the eighth extent descriptor in its extend record has a non-zero block count)
* The system uptime is at least 3 minutes
If all the above are satisfied, the file is relocated (de-fragmented) - on-the-fly.
Another optimization is "Hot File Clustering". This is a multi-staged (the stages being DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION and ADOPTION) clustering scheme that records "hot" files (except journal files, and ideally quota files) on a volume, and moves "hot" files to the "hot" space on the disk (0.5% of the total filesystem size located at the end of the default metadata zone - at the start of the volume). The scheme uses an on-disk B-Tree file for tracking (/.hotfiles.btree on a volume):
# ls -l /.hotfiles.btree -rw------- 1 root admin 196608 17 Dec 10:09 /.hotfiles.btree
At most 5000 files, and only files less than 10 MB in size are "adopted" under this scheme.
I found this information from
http://www.kernelthread.com/mac/osx/
from a Slashdot article here:
http://apple.slashdot.org/article.pl?sid=04/01/07/1615230&mode=thread&tid=179&tid=185&tid=190
The specific information is listed in "Mac OS X Filesystems" section.
Now, here's a direct quote of what I'm referring to:
HFS+ also has a few specific optimizations. When a file is opened on an HFS+ volume, the following conditions are tested:
* The file is less than 20 MB in size
* The file is not already busy
* The file is not read only
* The file is fragmented (the eighth extent descriptor in its extend record has a non-zero block count)
* The system uptime is at least 3 minutes
If all the above are satisfied, the file is relocated (de-fragmented) - on-the-fly.
Another optimization is "Hot File Clustering". This is a multi-staged (the stages being DISABLED, IDLE, BUSY, RECORDING, EVALUATION, EVICTION and ADOPTION) clustering scheme that records "hot" files (except journal files, and ideally quota files) on a volume, and moves "hot" files to the "hot" space on the disk (0.5% of the total filesystem size located at the end of the default metadata zone - at the start of the volume). The scheme uses an on-disk B-Tree file for tracking (/.hotfiles.btree on a volume):
# ls -l /.hotfiles.btree -rw------- 1 root admin 196608 17 Dec 10:09 /.hotfiles.btree
At most 5000 files, and only files less than 10 MB in size are "adopted" under this scheme.
ElDiabloConCaca
U.S.D.A. Prime
True, but OS X's automatic defragmentation is not a full defragmentation.
I doubt anyone would see any boost in performance/speed/reliability from a full defragmentation anyway. If you notice, even after you do a full defrag, your disk becomes fragmented again very quickly. UNIX/Mac OS X puts files where it wants to, and defragmenting just puts those files somewhere else. Upon usage for a few days/weeks, you'll see that your disk is defragmented again -- only because UNIX/Mac OS X moved the files back where it wants them to be.
Defragmenting is quickly becoming a thing of the past for Macintosh users. It no longer provides the speed/performance boost it did under OS 7/8/9.
I doubt anyone would see any boost in performance/speed/reliability from a full defragmentation anyway. If you notice, even after you do a full defrag, your disk becomes fragmented again very quickly. UNIX/Mac OS X puts files where it wants to, and defragmenting just puts those files somewhere else. Upon usage for a few days/weeks, you'll see that your disk is defragmented again -- only because UNIX/Mac OS X moved the files back where it wants them to be.
Defragmenting is quickly becoming a thing of the past for Macintosh users. It no longer provides the speed/performance boost it did under OS 7/8/9.
ElDiabloConCaca
U.S.D.A. Prime
No, as far as I know of, there is no terminal command to report levels of disk fragmentation.