6

My scenario:

  • My HDD is fully defragmented and must be kept defragmented.
  • Free space must be fully defragmented (no small gaps) so when copying new files with iso2opl they aren't fragmented.

I think the only solution is to make the existing files "slide" toward the beginning of the disk.

Options I've already discarded:

Options I'm considering:

IMPORTANT EDIT: Forgot to mention my HDD is formatted in FAT32 and it is not a system drive!

2

3 Answers 3

2

You may not be able to

If there are any unmovable files on the disk it is very likely that you will not be able to have both 100% defragmented files AND 100% defragmented free space at the same time. This is because the amount of space between unmovable files may not have any combination of your files that are the same length. Plus the unmovable files themselves may be fragmented.

From memory FAT32 stores its directory structure in unmovable files, though it has been a lot of years since I've really used FAT32. Yes a directory is stored as a file on the disk that essentially contains a list of the files and folders inside it and where on the disk each of them starts. As you add more files to a directory the size of the file storing the directory information grows. This can become fragmented. NTFS allows you to defragment the directory files too.

If this is also a system drive there will be some unmovable system files too. You can get around this by putting the disk in another system or booting up from another drive/cd/dvd/usb/etc.

The developer of jkdefrag renamed his product to MyDefrag. I know that the MyDefrag tool allows you to wrap a file around unmovable files, such that the free space is 100% consolidated, and all of the movable files on the disk are in sequential order, like defragmented files, but with the unmovable files in between segments of the file. This will show the files as fragmented, but reading them will still be very fast due to them being on the disk in sequence. Reading one of these files that wrap around the unmovable files will occur in sequential disk logical block address order but with a few gaps here and there. The length of time it takes a disk to skip reading some sectors is VERY short.

Edit: Also, just because there is open free space does not mean windows or for that matter Linux will use the space you expect in a sequential nature when adding new files. You may have to defragment anyway.

2
  • luckily this is not a "system drive" with unmovable files, it only contains splitted ISOs (1GB each part) in the root dir, nothing else.
    – eadmaster
    Feb 26, 2014 at 19:51
  • then the file storing the root dir will be growing and unmovable. From the looks of that site your best bet is to ensure 100% defragmented files and put up with having to defragment every time you make changes to the disk before you use it with that software. Feb 26, 2014 at 20:13
1

Free space must be fully defragmented (no small gaps)
...
Options I've already discarded:
...

At the time of writing, Defraggler has been updated to also allow file fragments to fill the free blocks. It is number two in the free space defragmentation modes listed below:

Defraggler has two options for defragmenting freespace:

  1. Normal mode: Defraggler only moves whole files to fill the free blocks. This mode minimizes the possibility of file fragmentation.
  2. Allow fragmentation mode: If Defraggler does not find any files that will fit completely into the free block, it will move file fragments instead. This mode is more efficient than the normal mode, but it may cause additional fragmentation.

I think the only solution is to make the existing files "slide" toward the beginning of the disk.

Defraggler will allow that. According to its documentation:

How Defraggler Defragments Freespace

Defraggler moves files or large file fragments in order to create a single continuous block of free clusters. It starts from the beginning of the drive, filling empty blocks with file clusters taken from locations later on the drive.

0

I am running Windows XP, and have dirms version 3.0.0.0 command-line utility from 2010 installed. From my understanding of this program's documentation, NTFS leaves a gap between files, such that a disk has fragmented free space. Second, if a smaller file is deleted from the drive, that opens up its space for reuse. If a larger file is added, even if there is a large enough segment of free space to hold this new file in one segment, the first, smaller space is used, and the file is fragmented as its remaining fragment fills the next available space.

Dirms packs files together, defragmenting free space and thus making larger segments of space available. This is done with the command line entry "dirms c compact" where the first "c" is the drive letter to be compacted. If defragmentation and moving files closer together via compacting are done, this reduces the tendency to fragment files.

Dirms cannot solve the NTFS issue with deleting a smaller file and then adding a larger file, for the new file will still fill the first available space vacated by the smaller, deleted file and then become fragmented. That is a file system fault. (Of course, a run of Dirms after deleting a file will avoid the fragmentation of the new file!)

I also understand from the documentation that dirms will reduce the number of fragments when there is not enough free space available to fully defragment a file. The built-in defrag tool will not even attempt to defragment a file if there is not enough free space in one segment to hold the entire file. Dirms contends that a partial defragmentation is still better than none, for it requires less drive head movement to read the file.

I have Auslogic's DiskDefrag 4.4.2.0 installed, and it has the ability to position system files first on the drive for rapid system responsiveness. I notice that it leaves a free space segment near the beginning whereas dirms will not. It could be the thinking here is to provide free space near the front of the drive for rapid read-write response on a freshly defragmented drive.

I get the idea that Auslogics also compacts files together, but their documentation is a bit skimpy on that point, versus the fairly in-depth discussion offered by dirms.

I did notice some performance boost after Auslogics' first run, reordering system files first.

Perhaps the best of both worlds is to periodically run Auslogics to place system files first and then compact with dirms. I don't know if removing Auslogics' up-front free space with dirms would materially take away from the system speed boost, but that would consolidate your free space to the extent permitted by the presence of immovable files.

The friend who put me onto Auslogics indicated a wish that the Auslogics would have allowed him to place the swap file up front, to possibly further increase performance.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .