martha : Java Glossary

To write an efficient disk defragger, model how you tidy your apartment, better still, how Martha Stewart tidies her house.

Implementation In Hardware

I thought of implementing a martha several ways. One is where the disk hardware transparently physically reordered entire tracks optimally. It snoops on disk activity to discover which tracks are accessed most frequently and which sequentially. Even if the OS were stupid enough to fragment a large file over many tracks, the martha could pull them together contiguously.

One problem would be a track containing both rarely and frequently used small files. Such a martha could not fix that. Ditto if a large file were badly fragmented so that it shared many tracks with other files.

Another approach is for the martha to remap every cluster to its optimal spot on disk. That allows it to move around even tiny files and system files dynamically. That approach makes the disk more vulnerable to crash from the even larger map getting out of whack. You might need to use flash RAM (Random Access Memory) so that power failure never caused you to lose the cached cluster map. You might handle the problem much the way NTFS (New Technology File System) or SQL (Standard Query Language) does with transaction updates to duplicate copies.

Another approach is for the disk itself (or a controller firmware or a martha-enabled driver) to implement an entire file system. The file system would have abilities similar to NTFS, ext3 etc, but cleverer. Its structure would be proprietary and hidden. This sealing could be used to provide extra security by closing the usual back doors. The interface to it would plug-in at the same level as a file system plugs into Windows or Linux. You can then start getting clever, with hardware-assisted faster file lookup, faster find, scanning with hardware, built-in SQL etc. Because of the higher level interface, you are free to experiment and compete on speed via intelligence without breaking any code.

As RAM gets cheaper and cheaper, it would make sense for all writes to be procrastinated, stored in cache and only physically written much later to an optimal spot on disk. In other words, you don’t let the disk get fragmented or disorganised. Every write gives an excuse to reposition that data. It is most important to keep the stuff you access most frequently tidy. Sending old stuff to the attic (remote regions of the disk) is a background task needed only to free up some space.

Miniaturisation will eventually make the it possible to fit multiple actuator arms inside the drive. Marthaing will give the extra arms something to do when the disk is not running flat out.

As disks get larger and cheaper, it may become economic to use a pair of disks, with background copy back and forth between them, reading and writing to both disks in some clever way, in a way transparent to the users. You are giving up some space to get back extra speed.