Best defrag program for FSX?

[jim1931]

I've heard that O&O Defrag is very good - appreciate comments and which option to use.

Jim

[Paxx]

If you have Vista there is a discussion about defrag programs, including O&O, here (http://www.flightsim.com/vbfs/showthread.php?t=181033).

[jim1931]

Thanks, I'm running XP Pro.

Jim

[Kurtvw]

I use Auslogics... it does a great job and its free.

[mjrhealth]

IObit 5.01 beta does a pretty good job, optimises as well and its free.

[rhodges]

I personally love Diskeeper2007_ Home Edition (There is probably a newer 2008 version).

It repeatedly drfrags on its own without me even knowing it is there.

When I occasionally manually run a defrag with it just to be sure it is still working and has been doing its job, it only takes seconds (for multiple large raid configurateion plus a separate large backup drive.

I would highly recommend it.

Good luck:
RTH

[joejam2]

Just downloaded IObit 5.01 beta today and it seems to be a good program. I am guessing said programs in this thread are better than the default windows defrag?

[Paperflyer]

I am using Linux/OSX and don't fragment in the first place.

On Windows however, I stick with windows' built in defragger.

[xxmikexx]

Paperflyer,

I suspect that, even on Linux/OSX, major scenery packages, with their large file counts must cause "slab fragmention" -- the kind of fragmentation discussed in the following article ... http://kerneltrap.org/Linux/Slab_Defragmentation

[Paperflyer]

Well, of course. After all, fragmentation is a feature, not a bug. It allows to save a file to the disk even though there is not enough contiguous free space on it. But that doesn't mean that every file should fragment by default!

And of course every filesystem has to cope with fragmentation in some way, so even Linux does have some built-in on-demand defragmentation of some kind. It just is complete anachronism to not do this automatically by the filesystem itself. This is quite amazing, as apart from that, NTFS is a very modern and performant filesystem.

[rpowers46]

There has been quite a lengthy discussion about this at Avsim.Search for Nick and defrag or O&O.Ron

[xxmikexx]

Paperflyer,

NTFS is not an anachronism. It is a robust and powerful file system sitting on top of an exec that is light years ahead of Linux in sophistication. OSX is more sophisticated than Linux but it still doesn't have the features of NTFS or the exec.

Most of the benefits of NTFS are hidden under the hood and have to do with file system integrity as well as with deliberate tradoffs between file system throughput and HDD space conservation, combined with automatic background rebalancing of the B*-tree Master File Table every three days.

I know whereof I speak because ...

DEC VMS begat
WinNT begat
Win2000 begat
WinXP begat
WinVista

The differences across these systems have mainly to do with the "shell" -- the user interface. The Windows API programming interface to the exec hasn't changed much over this period since it was grafted onto VMS to make WNT, and the exec itself is unchanged in philosophy because it's hard to improve on a Lamborghini. (But it's easy to improve on a dune buggy, which is what Linux is, and what UNIX is -- fast, but can't carry a complex load efficiently.)

I was at DEC at the time the system was being designed, including the file system, and said design contained then all the important features that it contains today. So I suppose you could say that it's an anachronism, but then you'd have to consider airplanes an anachronism, since the principles of airframe design haven't changed in 75 years, just as the principles of operating system design haven't changed since the mid-70s.

[xxmikexx]

P.S. ...

You can read more about the importance of defragmentation strategies in my article series regarding FSX which begins here (work backwards from this article) ... http://www.flightsim.com/cgi/kds?$=main/op-ed/ed395.htm.

If native Linux is capable of doing an alphanumeric sort of the on-disk folders and files structure, I'm not aware of it. (Nor am I aware of any third party defraggers for Linux that will do this job, though I could be wrong.)

Phil Taylor, Microsoft's FS product manager, recently read this article series of mine and confirmed the correctness of the recommended defragmentation strategy.

xxxxxxxxxxxxxxxxxxxxxxxxxx

And by the way, the Vista defragging thread here on FlightSim.com referred to earlier by Paxx, http://www.flightsim.com/vbfs/showthread.php?t=181033 is about Windows defragging in general, not just about Vista.

[Paperflyer]

please read my post again:

[...] Apart from [the lack of automatic defragmentation], NTFS is a very modern and performant filesystem.
I did not say that NTFS was an anachronism. I merely stated that it is about the only modern filesystem that needs to be defragmented with an external program.

But you are right, lets drop this debate here, as we are unlikely to come up with something that has not been said alread by someone ;)

[xxmikexx]

Paperflyer,

You wrote "It just is complete anachronism to not do <defragmentation> automatically by the filesystem itself." Actually, I do have something new to say on that subject ...

Suppose you are (the designer of) an operating system. Imagine that you are running an application that happens to be FS installing itself and you would like that operation to complete as quickly as possible. At least two and probably several output files will be open at once -- the current scenery file, the current scenery catalog file, and perhaps other files representing other aspects of storing and cataloging scenery.

You, the exec, have only a finite amount of memory to devote to buffering file output. This imposes a goal of getting rid of data to HDD as quickly as reasonable. How do you do this? There are two basic strategies ...

xxxxxxxxxxxxxxxxxxxxxxxxx

1 - You can plan to create every file as contiguous. Of course you don't know how long each file is going to be, only that there are N of them open, so you will take disk free space and conceptually divide it into N long potential files. You will, in other words, reserve contiguous space for each file, and the reservation will last until the file is closed.

Note, however, that this strategy requires moving the HDD head positioner assembly each time data is to be written to disk -- because you have to move the heads to the region of the file to which the data belongs. If you don't do this, or if data is arriving at a faster rate than you can move the heads so to speak, then your buffers will saturate and you will have to block the application -- you will have to slow the application down, throttling its output rate till it matches your ability to get rid of data to disk.

xxxxxxxxxxxxxxxxxxxxxxx

2 - You can say "I've got a bunch of data to be written to HDD, on behalf of multiple files. This data wants to be written to disk as quickly as possible so instead of reserving space for each file in a separate region of the disk, I'll just write the stuff out to the current track, making notes along the way as to where I put each sector of data belonging to each file.

This way I will suffer only minimal HDD seek times, and my system throughput will rise. The result will generally be fragmentation of newly created files, but many applications will tolerate this because the rates at which they read data are fairly low, and the exec's file data prefetch algorithm will compensate.

And for those cases where these assumptions turn out to be wrong, let there be a defragger that runs at a later time. I'm too busy right now trying to pump data to HDD at the highest possible overall rate.

xxxxxxxxxxxxxxxxxxxxxxxx

So which is the anachronistic approach? The one that optimizes speed of writing? Or the one that minimizes fragmentation at file creation time?

Oops, I forgot ... Winky winky.

xxxxxxxxxxxxxxxxxxxxxxx

Never bring a cult operating system user mindset to an operating system design fight.

[Paperflyer]

Are you referring to me as an "cult operating system user"? Thats rather unfair: I am using Vista, OSX and Linux about equally. If anything then I am very operating system agnostic. I really believe that one can work with all of them -- I do it every day! (My first post to this topic actually came from Vista, the second from OSX and the current from Linux)

OK, so the "complete anachronism" was unfair.
But I never, never, never intended to say that Windows/NTFS/You sucked. I really never did. I really never did, because I really do not think it does. I only pointed out that there is just no such thing as a defragmentation application outside the Windows world.

But now you got me started, lets elaborate on the subject.

As I have mentioned, I can not have inside knowledge of how NTFS works. Supposedly, however, it would like to assemble every file as a contiguous block of data on the disk, if possible even in alphabetic order. This is the ideal arrangement for single-big-file-performance.

Unix filesystems are different, in that most of them are optimized for multi-file-performance. They assume that the only really time-consuming thing a hard drive can do, is to change its current cylinder (move the reading/writing heads). Hence, they optimize their data to be stored in a single cylinder (or at least near cylinders). Within a cylinder the data does not have to be written in a contiguous block as long as it is written in continuous order. Coupled with some efficient prefetching routines and a clever ordering algorithm for pending reads/writes this system is only marginally slower when reading single big files and in most cases a bit faster when reading many small files.
However, as _every_file_ is fragmented within its cylinder by default, there is no need to defragment, since the filesystem is actually meant to fragment (orderly) to reach peak performance.

Measurements of XFS show exactly that behaviour. Of course older filesystems like Ext3 are much slower than NTFS and state-of-the-art systems like ZFS show performance that is just enormous.

With Vista, defragmentation is very inexpensive in performance and can be safely set up as a regular job. This way, it needs no more user interaction than any other filesystem and is equally fast and reliable. Probably this is equally easy to set up in XP, but I don't use it any more, so I can't check. Hopefully the next Microsoft filesystem (currently dubbed "WinFS" and planned for the next Windows) will address this issue and free the user of yet another task to worry about.

[xxmikexx]

Paperflyer,

I have done system programming on UNIX and Windows 9x/2k/XP/Vista. I have been a user of OS7/8 and of Linux.

I'm willing to debate the cult operating system matter in the Software Tech forum. See you there.

[Paperflyer]

Right you are.

[MXP]

A good one is the freeware Auslogics Disc Defrag.

[xxmikexx]

MXP and Readers,

I'll try out the Auslogics program and report back here. I've got the tools to assess how good a job it does.

[jimmymac]

My only comment is, the person asked a simple question, and I assume, wants a simple answer. I would want a simple answer. I can appreciate all of the comments, but it seems to get off track a lot, and then people are all of a sudden throwing spears at each other, and in a lot of cases, the questions go unanswered, and do get quite technical. Just an outside observation.

[Paxx]

MXP and Readers,

I'll try out the Auslogics program and report back here. I've got the tools to assess how good a job it does.

Any results xxmikexx?

[xxmikexx]

Paxx,

Re Auslogics, kindly see my post #26 to this thread ... http://www.flightsim.com/vbfs/showthread.php?t=181923.

[Paxx]

Thanks Mike.

[jimmymac]

Another excellent defrag program is Ultimate Defrag 2008. It also has a trial period for free. It is by disktrix. Go to their website, check it out.

[MXP]

Hi, I don;t know if this is still running, but I can solve your speed prblem with Auslogics:

Go to Settings > Program settings > Defragmentation > Put CPU usage on highest.