Move system files to fastest sectors (again!)

[forbin]

Sorry to duplicate previous topics, but none of them have had any activity for at least five months.

 

Is Piriform considering adding the option to move the system files to the fastest part of the disk?

Or has the idea been relegated to the dust bin?

 

Currently, I'm having to use 2 different defrag programs to achieve (nearly) what I want!

 

I run Defraggler and a not-to-be-named-competitor (which I will call NTBN for the purposes of this post). The NTBN defragger can move the system files, but it cannot put the really large files at the opposite end of the disk. What it can do is to completely ignore files larger than a threshold size.

 

So I'm forced to run Defraggler (which I vastly prefer) to achieve "initial" defragmentation and move the big files out of the way... then I run NTBN, having it skip these large files, just so it can get the system files where I want them.

 

My system run noticeably faster than when I was only running Defraggler. Unfortunately, I didn't benchmark anything and now there's probably no point in trying to do it on my already-optimized machine.

 

It is probably a safe assumption, though, that if Piriform added the feature to Defraggler, they could do a better job than "the other guys," and the whole process would take less time since it would be accomplished in the same single defragmentation pass.

 

 

[if someone wanted to try to collect benchmarks, I could give you the details of how I'm running the two pieces of software. Does anyone have a really nastily fragmented old disk they could use as a benchmarking platform? We'd need to collect baseline measurements of the disk as-is, then run Defraggler with the same settings I use and benchmark that as "without the system move feature". Then we'd run "NTBN" with my settings, and benchmark the disk performance after that as "probable performance using the proposed feature plus the 'move big files' feature."]

 

 

Thanks!

-- forbin

[Super Fast]

Forbin, as previously stated, I also had a similar idea, but mine involved moving either all system files to the fastest part of the drive via their system attributes, then the user files & folders, then free space, or else:

 

- C:\Windows - > 100% system files. Move to fastest part.

- C:\Program Files -> Mix of user + system files. But still, probably more system files for the most part. -> Right behind C:\Windows.

- C:\Users -> May be more system or user, depending on number of files added to user Docs etc, so -> Right behind C:\Program Files.

- C:\ -> All other files -> Last

_____

 

Not sure if they will implement it, but the way I see it is this:

Legend: FS = Free Space / UF = User Files / SF = System Files

 

Unfragmented Drive: FS/UF/SF/UF/FS/UF/FS/SF/SF/FS/SF/UF/FS/UF/SF/SF/UF/FS

Defragmented Drive: SF/UF/SF/SF/UF/SF/SF/UF/UF/UF/SF/UF/FS/FS/FS/FS/FS/FS

My Suggested Drive: SF/SF/SF/SF/SF/SF/UF/UF/UF/UF/UF/UF/FS/FS/FS/FS/FS/FS

_____

 

The problem with the current method, is it throws user + system files together. So even though the free space is consolidated & files are not fragmented, the drive still has to skip across system files to locate user files, & makes the drive "File Fragmented" in that sense.

 

By applying this simple fix, it would put all System Files together, followed by User Files, then Free Space.

This would increase speed, because all System Files would be together, which would eliminate having to hop across so many User Files to locate the System Files to run.

 

Currently, Defraggler consolidates free space + unfragments fragmented files, but it doesn't take it one step further & eliminate "file" fragmentation, where even though all files are contiguous files, Windows still has to jump user files to load Windows files.

 

I hope it gets fixed!

[forbin]

SuperFast:

 

Thanks for the support and the feedback!

 

Yes, this is the kind of thing that I had envisioned as well, though I suspect that the folks at Piriform have more time and expertise than we do (even though I have been a systems-level programmer in my previous job incarnations) --- which would hopefully enable them to try a few variations on your scheme to determine what would do the most good.

 

For example, one might be able to analyze the registry and certain folder locations (such as %SystemRoot%\System32\Drivers\) and look at files by type (.exe, .dll, .sys, .vxd, etc.) and by creation/modification/access date and put together a pretty clear picture of what files are "system" files or "frequently accessed executable files" as opposed to other types of files.

 

I'd rather not attempt to artificially constrain the developers in trying to request a very specific layout. However, it just occurs to me that these two paragraphs are probably more to the benefit of other users than to the Piriform developers; the developers are smart and knowledgeable enough to read "eliminate having to hop across so many User Files to [access] the System Files" and figure out what it is that we really want.

 

 

regards,

--- forbin