What would be a good defragmenter program for a home user on a laptop, 160 GB HD, about 85% used.

Windows defrag (Diskeeper Lite, old version) does not defrag system files such as page file & is also slow.

thanks, just installed jkdefrag

It's good & offers 3 diff d/ls (3 diff .exe's), incldg a Cmd Line ver with lots of options. As I am not an expert, I prefer the std .exe.

Apart from above, I also use Page Defrag (another stand-alone .exe) for defragging the page file & other system in-use files (defrags on next boot), ... to avoid page file fragmentation, it's suggested to keep the max=min page file size each equal to about X2 system RAM (an often quoted rule-of-thumb).

HTH

Shadow,

Quote:

Wasn't trying to contend your position or compare/contrast programs,
Just pointing out what worked for me.

Quote:
Switching to those new file systems would also mean switching to a new os, a bigger chore than defragmenting the HD!

Quote:
I am extremely vary of 3rd party utilities...

Anyways, was able to get a decent performance gain on NTFS with Win XP with a fragmentation level of 3-4% using above 2 programs, and happy with that.

zmdmw52 wrote on Jun 20^th, 2008 at 8:12pm:

Indeed. It's also the case that the claim they don't fragment is outright nonsense; they do, and indeed they must, no filesystem is immune to it. Fragmentation is a mathematical inevitability; the only way it can be eliminated is by moving things around later; some filesystem implementations try to rearrange space online more transparently, but it's really only a question of when the work is done.

Indeed, the filesystem designs themselves don't have much to do with encouraging or avoiding fragmentation, unless they choose to put the data that describes where the file data is far distant from the data itself (as FAT-style filesystems do). For most modern filesystems, they have enough freedom in where things go that almost any allocation policy can be applied to it to determine where both use data and the filesystem meta-data blocks are put, and these policies can improve over time. Some policies do better for some workloads, and so there's a degree of tuning that can be done where it matters.

[ Fragmentation is a phenomenon studied in many contexts, not just filesystems. It affects memory allocation within programs as well, and appears in all kinds of real-world contexts studied in operations research. Anyone who claims something "doesn't fragment" is claiming an outright impossibility, on the same level as a perpetual motion machine or infinite data compression. ]

The other thing is that fragmentation only really appears at a level which becomes a problem in filesystems which reach a high load factor. Below 80% load, almost no modern filesystem has any trouble at all, and most do well up to 90% (at which level the "lite" defragmenter in Windows 2000 and above stops working, just when it's actually necessary!). The best investment you can make is generally in more space (and/or faster disks, of course), so that the filesystems have plenty of room to choose to apply their allocation policies.

It's also worth pointing out that of all the things on a disk, the pagefile is a special case; because of the way operating systems read from it in response to page faults, it matters much less if this file is fragmented compared to almost anything else, because the contents are almost never read sequentially. Because the access to it is so poorly clustered, it doesn't gain any benefit from sequential organization on disk as long as the filesystem cluster size is greater than the virtual memory page size.

[ It's worth noting that FAT32 systems converted in-place often have an allocation cluster size of 512, and this is very very bad for many reasons.  It's best to use an allocation unit of 4k or so at a minimum, which is the NTFS default and indeed the most filesystems use that or something larger. ]

All that said, ZFS is a particularly excellent filesystem design, and the engineers at Sun have done fine work on it. It will be interesting to see it turn up on more platforms in future.