However, as files are added, deleted and
change size, the volume becomes fragmented so that there are only small holes of available sectors in which data may to be disposed.
In other words, the
operating system and the drivers have full access to the system memory and may bypass safety mechanisms when objects that normally are protected are to be accessed.
In fact, this
vulnerability was one of the causes for introducing driver signature in
Microsoft Windows 2000 warning the user if installation of unauthorised (unsigned) driver is attempted installed.
However, the call does not necessarily reach right down to the disk.
Firstly, a file is to be opened before it can be defragmented. If the file is locked by another process, or the application does not have the required rights, it cannot be opened and not defragmented either. Even with
superuser rights it is normally not possible to open locked files.
Secondly, it is only discovered that a file has been fragmented when the user is running his
defragmentation application. In other words, files may be fragmented for a long time if the user is not in the
habit of running his defragmentation application regularly. Files that are often in use may be strongly fragmented without the knowledge of the user.
Thirdly, it is required that the user starts his defragmentation application by himself if the user desires to defragment his disk. Many users are not paying attention to defragment regularly, or they are also not even aware of the problem. Other users are reluctant as they do not want the defragmenting application to take resources from other running applications. The problem is normally solved by letting the defragmenting application run at certain times where the system is not occupied by other tasks, e.g. every night. This is also inconvenient because it forces the user to let his computer be switched on all night.
Fourthly, defragmentation applications dull other running applications. This is not only due to the fact that they have to share the
CPU time with other applications. This is particularly due to the fact that they have to share the disk with other applications. When a file is defragmented, the disk is occupied, and other applications may neither read nor
record to the disk in the meantime. It does not help much to give the defragmentation application low CPU priority. If an application sends an I / O request to a disk, its thread goes into a
wait state until the I / O request has been executed, unless it has other things to do. If there are no other threads waiting to get
CPU time, the defragmentation application is allowed to get on, even if its thread is running with the lowest possible CPU priority. Its I / O requests will thus interfere with other I / O requests, irrespectively of the CPU priority. In other words, a defragmentation application will always compete with other programs about getting its I / O requests through. The problem is only worsened if the system has several CPUs, or the CPU has several cores.
However, the user has to wait for the buffer in the memory to be filled when the file is opened.
However, the technique does not solve the problem that simultaneous processes accessing the disk during defragmentation experience delays in their I / O requests.
The method causes
delay of the initial I / O request and the same problem with parallel I / O requests.