[Move to end of disk and leave space for expansion]

I haven't used the "move large files to end" option, but...

 

Now, the problem is that the virtual machine disks are huge. I have configured it to move the big (>10gb) files to the end of the disk, however if you stop defraggler and restart it, it finds that the last file on the disk has extended by a few Mb and it starts moving the 200Gb of virtual disk files in front of it to make a space - it never finishes and ends up moving the last file on the disk constantly rather than defragmenting the remaining virtual disks.

In the interim, when that happens, stop it, add an exclusion for the file it won't get past, then restart it.

Would it be possible to add a way to leave a gap for expansion?

I would think a "move to end" option without this would be of limited utility.

Now I realise that this generates another problem. On the next defrag the gap will have reduced due to expansion and so the logic would say to move it again to increase the gap size, which would defeat the purpose.

 

Maybe a facility which allowed the sysadmin to specify position on the disk for a file. I'm thinking specifically of defragmenting servers where you always have big files.

Pssst. Why are you using NTFS? Go to ext3/4 and never think about it again.

Maybe a 'don't touch the first fragment of this file' marker. At least this would allow us to defragment these files down to a couple of fragments.

 

Anyone got any good ideas? What other tecniques exist out there? Everyone has got to be hitting the same problem.

I'd think the simplest solution to this would be similar to the one used in thermostats to keep them from constantly cycling on and off: make your target significantly "safer" than your threshold. For example, when the trailing free space is less than... idk, 5% of the file's size--or maybe just when it reaches zero and starts fragmenting-- trigger a move and/or defragmentation that'll leave it with, e.g., 15% to spare. It won't be moved again until it's eaten up the difference.

You could apply this for not only the last file on the disk, but each one ahead of it. So it'd be targeting a certain amount free space after each file, regardless of whether the end of that space is marked by another big file or the end of the disk.

 

I have a really cool (I think ) idea growing off this--a particular AI-driven proactive defragmentation--but... I can't just offer it up for free!

["Finished" message]

Some people may not like that. Maybe build in the option to tick whether they want to be alerted when it is done. Perhaps even build defraggler with "download" packs.

 

Meaning, why add colorblind support to Defraggler if someone does not use it, it would not be added to the download size & just add something that is useless to them. Perhaps be able to download the parts they want to use with Defraggler.

 

Say, downloadable:

 

- Language pack (for languages other than English, instead of installing all of them)

- Alerts (for users who really really want to add that)

- Colorblind support

 

Etc, etc!

 

Have you ever maintained software?

 

A colorblind user should just customize the colors to ones they can differentiate. (There's more than one type of colorblindness anyway.)

 

As for languages, I have the same thought when I see a program installing DLLs for languages I don't speak, but each should just be an option in the installer, not a whole other download. (They're not large enough to warrant that, in my opinion.)

 

The file size increase associated with an option to alert the user would be trivial.

["Finished" message]

It'd be a feature as long as it were an option and not an imposition! Otherwise, you'd just get feature requests that it be removed.

[Solid State Drives "SSD"]

Solid state drives do not need defragging because there is no delay associated with fragmented files, furthermore because flash memory has limited write cycles you should avoid excessive writing.

Btw...anyone out there defragging their USB thumb drive, those're flash memory, too.

 

I'm not sure excluding SSDs from Defraggler is such a good idea in the end of the day if the owner wants to defrag their drive then it's their choice.

Agreed. A warning would be fine, but stay away from hard-coded blanket assumptions that "software knows better than user". Offer the user your advice, but at some point just do as they say.

 

There's at least one benefit of defragmentation that still applies for SSDs: recoverability. If a file system gets corrupted, you stand a MUCH better chance of recovering contiguous files than fragmented ones. (The degree to which that's an understatement depends on the particular file system and nature of the data, to my knowledge. )

 

The practicality of even determining whether a drive is SS or not may well be an issue. The driver and OS intentionally abstract the details of file storage volumes. Unless Windows is aware of the difference and makes that info available through an API, a program might have to go to the effort of maintaining a database of vendor and device ID codes.

[Remove typed paths]

Someone's gotta want this besides me?

 

I do! Piriform, please cover all the histories kept by various parts of the Windows OS before worrying about the countless 3rd party apps out there.