Defragment Hard Disk Faster With Java Defrag
The importance of disk defragmentation is often under estimated for speeding up a computer. Defragmentation reduces scattered files by physically organizing the contents of the mass storage device to store files in a contiguous region (if possible). Which improves the read/write rate of a hard disk due to defragmentation of files.
Java Defrag is a portable application for quickly defragmenting NTFS and FAT32 hard drives. What makes open source Java Defrag different than other defragmentation applications is that it is less resource intensive and utilizes the standard Windows Defragmentation API for moving files on NTFS hard drives. Binding the files together in this way can provide a number of advantages, such as improving the loading time in games and reducing lags.
Just launch Java Defrag and select a system partition to defragment (e.g. C Drive).
Once a partition is selected, it will be defragmented in no time. You can use the F5 hotkey for displaying the number of available drives for defragmentation. Clicking on a section of the drive map displays the cluster range, whereas, middle click allows toggling the maps view. CTRL+Mouse Wheel can be used to enhance visual visual cell size of the available drive map.
Despite being a Java powered application, Java Defrag displayed a memory stamp of approximately 90 MB (during testing) which is quite reasonable, considering that my Firefox browser is consuming 203MB of system memory. Java Defrag works on Windows XP, Windows Vista and Windows 7.
Some clarifications:
It does not defrag anything but merely displays a disk map. Defragmenting an NTFS drive is a very complicated and hard-to-do-fast method due the nature NTFS journaling frees blocks, lots of partial move-rejection errors due disk activity, case of immovable files, etc. Other tools have it hard too. My idea was to implement a different file-sorting mechanism than commonly found in other products, e.g. the ability to pick a concrete directory and move all files to the beginning of the drive. Unfortunately, I had little time or interest since Sept. 2010 to do this final implementation step.
The speed of the drive mapping is due the trick of opening the entire NTFS or FAT32 partition as a raw byte stream and reading large chuncks of the $MFT or FAT tables via the regular readfile methods: it reduces the number of times Java needs to go back and forth between the native and normal mode. Everything else is I/O bound, therefore, you rarely find noticeable speed differences.
It uses standard windows defrag API elements, which are guaranteed to be safe; but this is true for all other tools as well.
It is written in java, but is not portable, e.g., you run it on Linux and try to use it on an NTFS drive: it won’t work.
Final thoughts: JavaDefragWin is more like a good start and a way to look into NTFS and FAT32 internals and perhaps use it to search for files by path or name much faster.
Thanks for the great analysis shane. Readers like me appreciate it.
Have you thoroughly tested this versus the stock MSFT defrag? I suspect that you are correct in your assumption, but memory management is the number 1 thing that a defrag could benefit from… an analysis of many left counters would be interesting, specifically the bytes per second from the physical disk.
It would be interesting to do a proper comparison. The only issue would be replicating conditions. In order to accomplish an unbiased and accurate comparison between two defragmentation methods, I would need two identical (in terms of data and fragmentation levels) hard disks to compare. The Java VM’s memory management would probably not be able to interact with the disk defrag API, as I would assume it runs with kernel-level privledges, something that (for obvious security reasons) the JREE does not.
Anything at kernel (or at least near kernel level) would have fairly efficient memory management to begin with. Let’s face it, it’s much more likely that Java would have a memory leak than the Windows kernel.
If it is the Windows API that is performing all the I/O operations, this application couldn’t possibly defrag “faster” than, say, the built in fragmenter tool. An application written in a lower-level programming language such as C++ or C would be much faster than this app, simply because each command doesn’t need to be interpreted by Java Virtual Machines into an intermediary language (bytecode), then executed at a lower level before it finally becomes machine instruction. These extra steps create a lot of overhead for each instruction before it finally gets to interface with the Windows API.
That said, the app does have some significant merits which are disastrously missed by this article. Namely:
– Running commands through the JVM allows the entire process (bar the actual WinAPI routines) to be managed by the Java Garbage Collector.
– Java is executed as managed code, so it is unlikely that any poorly written code could adversely affect Windows.
– Java has fairly good graphics libraries, so the GUI’s drive map has the potential to be more powerful than other apps.
– The app is open source (ok, you did mention this one) so it could be useful to other devs as a fairly good implementation of the Java Native Access Library, and what it can achieve.