O Amp; O Defrag

[Timothee Cazares]

Fragmentationoccurs on every computer. When files are saved, they are chopped up and stored in individual pieces on the hard drive or SSD wherever there is space. Defragmentation reverses this storage chaos. A defragmentation re-sorts the saved files and puts them back together.

No difficult decision as to which is the best defragmentation strategy for your PC. O&O Defrag takes care of everything itself. All you have to do is choose whether you want to start O&O Defrag yourself manually or whether you want it to take care of everything automatically.

Checking and repairing the Windows rescue environment: The rescue environment is essential for both a functioning Windows and Defrag IntensiveOptimize. On many computers, the Windows rescue environment is damaged, for example due to incorrect updates, and is therefore unusable. We have therefore expanded Check&Repair in O&O Defrag 28 so that your Windows rescue environment works reliably like it did on day one.

Over time, more and more ballast accumulates on a PC. Temporary files, Internet cache and the like can take on considerable proportions. This can lead to a storage space problem, especially on modern SSDs. But backups also take much longer than actually necessary.

O&O Defrag 28 now clearly shows you all installed programs. And with one click you can easily uninstall what you no longer need. This saves storage space (important for SSDs) and increases your security.

* O&O Syspectr is an additional service from O&O Software that requires registration and can be used free of charge for 1 year as part of this offer. O&O Syspectr does not extend automatically (no subscription), but can be extended upon request for a fee.

There's a general rule of thumb or statement that "defragging an SSD is always a bad idea." I think we can agree we've all heard this before. We've all been told that SSDs don't last forever and when they die, they just poof and die. SSDs can only handle a finite number of writes before things start going bad. This is of course true of regular spinning rust hard drives, but the conventional wisdom around SSDs is to avoid writes that are perceived as unnecessary.

One of the most popular blog posts on the topic of defrag and SSDs under Windows is by Vadim Sterkin. Vadim's analysis has a lot going on. He can see that defrag is doing something, but it's not clear why, how, or for how long. What's the real story? Something is clearly running, but what is it doing and why?

As far as Retrim is concerned, this command should run on the schedule specified in the dfrgui UI. Retrim is necessary because of the way TRIM is processed in the file systems. Due to the varying performance of hardware responding to TRIM, TRIM is processed asynchronously by the file system. When a file is deleted or space is otherwise freed, the file system queues the trim request to be processed. To limit the peek resource usage this queue may only grow to a maximum number of trim requests. If the queue is of max size, incoming TRIM requests may be dropped. This is okay because we will periodically come through and do a Retrim with Storage Optimizer. The Retrim is done at a granularity that should avoid hitting the maximum TRIM request queue size where TRIMs are dropped.

When he says volume snapshots or "volsnap" he means the Volume Shadow Copy system in Windows. This is used and enabled by Windows System Restore when it takes a snapshot of your system and saves it so you can rollback to a previous system state. I used this just yesterday when I install a bad driver. A bit of advanced info here - Defrag will only run on your SSD if volsnap is turned on, and volsnap is turned on by System Restore as one needs the other. You could turn off System Restore if you want, but that turns off a pretty important safety net for Windows.

First, yes, your SSD will get intelligently defragmented once a month. Fragmentation, while less of a performance problem on SSDs vs traditional hard drives is still a problem. SSDS *do* get fragmented.

It's also worth pointing out that what we (old-timers) think about as "defrag.exe" as a UI is really "optimize your storage" now. It was defrag in the past and now it's a larger disk health automated system.

Additionally, there is a maximum level of fragmentation that the file system can handle. Fragmentation has long been considered as primarily a performance issue with traditional hard drives. When a disk gets fragmented, a singular file can exist in pieces in different locations on a physical drive. That physical drive then needs to seek around collecting pieces of the file and that takes extra time.

This kind of fragmentation still happens on SSDs, even though their performance characteristics are very different. The file systems metadata keeps track of fragments and can only keep track of so many. Defragmentation in cases like this is not only useful, but absolutely needed.

SSDs also have the concept of TRIM. While TRIM (retrim) is a separate concept from fragmentation, it is still handled by the Windows Storage Optimizer subsystem and the schedule is managed by the same UI from the User's perspective. TRIM is a way for SSDs to mark data blocks as being not in use. Writing to empty blocks on an SSD is faster that writing to blocks in use as those need to be erased before writing to them again. SSDs internally work very differently from traditional hard drives and don't usually know what sectors are in use and what is free space. Deleting something means marking it as not in use. TRIM lets the operating system notify the SSD that a page is no longer in use and this hint gives the SSD more information which results in fewer writes, and theoretically longer operating life.

However, this stuff is handled by Windows today in 2014, and you can trust that it's "doing the right thing." Windows 7, along with 8 and 8.1 come with appropriate and intelligent defaults and you don't need to change them for optimal disk performance. This is also true with Server SKUs like Windows Server 2008R2 and later.

No, Windows is not foolishly or blindly running a defrag on your SSD every night, and no, Windows defrag isn't shortening the life of your SSD unnecessarily. Modern SSDs don't work the same way that we are used to with traditional hard drives.

Yes, your SSD's file system sometimes needs a kind of defragmentation and that's handled by Windows, monthly by default, when appropriate. The intent is to maximize performance and a long life. If you disable defragmentation completely, you are taking a risk that your filesystem metadata could reach maximum fragmentation and get you potentially in trouble.

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

I've read through a bunch of posts and checked the usual culprits regarding hidden files and old snapshots (I am not running snapshots). I just now figured out that this thing has never had a scrub, defrag, or balance done.....BAD ON ME!!!!

I've seen a couple posts where it was recommended to do maintenance in the following order: scrub, defrag, balance. I took that to be "regularly scheduled maintenance". In my case, I am doing a massive cleaning of a system that has been woefully neglected and want to see if anybody recommends I change the order for this initial shot of TLC for this system.

Also, can I use the system at all when this is going on or should I make sure it does not get used when this is taking place? I'm trying to do it over the weekend when the business is not open but if it is still working through the process(es) come Monday morning when they need to use it, I need to know whether to stop the process or just let them know performance may be a little degraded.

Quick update......balance and defrag took some time (couple hours each) but were as expected. No increase in free space when they completed but I know each was needed. The scrub took 2 days to complete but when it was done, I reclaimed nearly 1.75TB of free space on my 4TBx2 system. Now my used/free space data looks correct.

btrfs itself provides progress information for scrub and balance. But defrag with btrfs is done file by file. So inserting progress information has to be done by the application. There is some concern that doing so would seriously increase the defrag running time.

Hi, here are some updated stats, we've spent time over new year putting in additional drives and changing the partitions, so we have a RAID10 partition that we use for iscsi connections and clustered storage. And a RAID1 partition that we use for backup so lots of data changing daily.

I suspected, for a long time, that since these DVR's are actually a dedicated computer device, that there must exist, somewhere, in the OP system a way to defrag and/or check for disc errors that *might* be a cause for a "laboring" system.

1. DO THIS ONLY WHEN YOU HAVE TIME TO SPARE!!! (Check to see if you have pending records in your list... they will lNOT record while going through this process) . (You will be inspecting the hard drive system... depending on how full your hard drive is this process may take from 1-3 or so hours to complete... but the results are fantastic!_

.......PRESS THE REC (Record button) AND the DOWN ARROW located on the lightened circle (navigator) on the HR20 unit... HOLD THEM DOWN... until...you see a screen that indicates your drives are being checked for errors. There will be a blue screen with two progress bars shown.

I have SQL Server Agent (2005) jobs that periodically perform CHECKDB and a defrag (ALTER INDEX REORGANIZE/REBUILD) of any index that is highly fragmented. These are typical maintenance best practices. I'm wondering which of the system databases I should apply these jobs to? Right now I run CHECKDB only on master, and I vaguely remember setting it up because I saw that in a book somewhere.

In my mind general checkdb would really only apply to master and msdb. You shouldn't have volatile data in model or tempdb (and Kin points out a good article on corruption in tempdb - should be much less of an issue if you move to a more modern version of SQL Server). I wouldn't bother doing this routinely against tempdb, but only deal with it if you actually get reports of corruption. IMHO. If you've added user objects to model so that they are created in every new database, that might increase the risk there so you may want to include it. Typically it is quite small so it doesn't really hurt to include it anyway.

3a8082e126