martha : Java Glossary


A program that dynamically keeps the most active files in the prime real estate near the outer edge (near the beginning of the disk) near the swap file and the directory, and the least active files and the bulk of the disk space in the inner tracks (near the end of the disk). This could be done on per cylinder basis, or per file or per cluster. A martha might live inside a hard disk’s firmware and operate totally transparently to the operating system, completely unaware of the operating system’s file and directory structure, working at the raw cluster level. The disk drive itself keeps a map of logical to physical disk addresses. It does all new writes in prime real estate and, in the background when it has nothing better to do, copies material not accessed for a while from prime real estate to the not so prime real estate to free up prime space. Data in prime space freed up this way is tracked in both prime and not so prime location. Reads are are done from the closest copy. The prime copy will likely be soon overwritten. The martha attempts to keep the data physically sorted in order by likely next access and likes to keep a pool of instantly freeable (but possibly occupied) space in the prime real estate. It constantly adjusts its logical to physical map so that the computer is totally unaware it is doing this. The computer just sees extraordinarily fast seeks. Write seeks are all fast. Read seeks are fastest to files or parts of the disk that have been accessed most recently. However, unlike a cache, the speedup effect falls off gently with time. The etymology of the term martha honours Martha Stewart, a woman known for her boundless industry and astounding powers of tidiness and organisation.


Implementation In Hardware

Here are some random thoughts on how you might implement a martha in hardware. The main advantage is the OS (Operating System) can’t corrupt the disk by crashing during the middle of tidying. Another advantage is the mechanism is OS-independent. It works even for obscure OS es and file systems for which there is no market to write a defragger. Another advantage is could use hardware assist. A hardware martha might better be able to prioritise real work over tidying work. To an OS, a software martha might appear just like any other user task.

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.

disk defragger student project that also touches on marthas

This page is posted
on the web at:

Optional Replicator mirror
on local hard disk J:

Canadian Mind Products

Your face IP:[]
You are visitor number