>>>>Second, I get the feeling you've got a bit of a bee under your bonnet on this topic, since George Tasker (to name one person) has dismissed your conclusions. However, it's a long way to go from, "fragmentation seems to help in some tests I've done in VFP" to "fragmentation helps most applications most of the time". You'll need to do a (hell of a) lot of testing to establish that - testing that will need to be consistent and repeatable (i.e. the scientific method ;-)) Put some real numbers to your assertions.
>>>>
>>>>If you don't think developing a fragmenting algorithm would be hard, then try it. The first step would be to write a hard disk emulator and then simulate read/write operations to it.
>>>
>>>What is the basis for your last statement?
>>
>>The lack of an alternative - do you have another suggestion?
>
>Are you saying that a Hard Disk emulator is a prerequisite in writing a File Fragmentation Utility? What is the purpose of the emulator?

Jim has proposed a fairly complex algorithm for allocating clusters to files such that they are purposely fragmented. To work optimally this algorithm will depend on the physical geometry of the HD in question, along with other factors like hardware track buffer size and type, whether the volume or files(s) are compressed, etc.

Of course it's not necessary to create an emulator in order to write a fragmenter. The purpose is to get an idea of how much performance improvement fragmenting may yield, and therefore whether the project is worth undertaking at all.

Building an emulator would do several things:

- demonstrate one's understanding of HD and file system operation
- allow virtual testing of a range of algorithm parameters without having to buy different physical hard drives
- eliminate issues of restoring or wiping disks/partitions clean between test runs
- allow one to specify the layout of file clusters on "disk" without having to write an actual low-level device driver to do this on a real disk

One alternative would be to do real tests with a bunch of real disks and a range of algorithm parameters, assuming you can write the data to disk in the exact manner you require. I'd argue that an emulator would be easier and certainly more flexible. Of course, the emulator would need to be compared to one or more real disks ;-)