To write an efficient disk defragger, model how you tidy your apartment, better still, how Martha Stewart tidies her house.
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.
available on the web at:
optional Replicator mirror
Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : . If you want your message, your name or email kept confidential, not considered for public posting, please explicitly specify that. Unless you state otherwise, I will treat your message as a letter to the editor that I may or may not publish in the feedback section. After that, it will be too late to retract it. If you disagree with something I said, especially when sending an ad-hominem attack, a rant composed mainly of obscenities or a death threat, please quote the offending passage and cite the web page where you found it, tell me why you think it is wrong, and, if possible, provide some supporting evidence. I can’t very well fix erroneous or ambiguous text if I can’t find it.
Your face IP:[18.104.22.168]
|Feedback||You are visitor number 11,412.|