The Storage Team Blog about file services and storage features in Windows and Windows Server.
When it comes to the defragmentation experience, simpler is not always better according to some very vocal Windows gurus. But is Defrag really all that simple? Turns out, there’s quite a bit going on under the covers, especially compared to Defrag in Windows XP. I sat down with one of the Defrag developers, Victoria House, to understand why our team is all jazzed up about Defrag.
There’s more than meets the eye with Defrag in Windows Vista. Tell me about some of these changes.One change that’s not obvious to users is our shadow copy optimization during defragmentation. Defrag has special heuristics to move file blocks in a way that will minimize the copy-on-write activity and shadow copy storage area consumption. Without this optimization, the defragmentation process would accelerate the deletion of older shadow copies.
A lot of customers complain that the Windows XP defrag is more thorough because running the Windows XP Disk Defragmenter against a Windows Vista volume reveals a lot of fragmentation. What gives?This misconception is due to our partial defrag algorithm in Windows Vista. We don’t try to make the volume 100% defragmented because defragmenting to the point where there are no fragmented files has negligible benefits. In our Defrag FAQ we state: “The performance benefit of coalescing two extents larger than 64 MB is minimal while the I/O load and free space requirements are significant. “ What this means is that the amount of time it takes to move the 64-MB fragment of a file is larger than the performance benefit you gain. This 64-MB figure comes from how long it takes to move and read/search a 64-MB file on an NTFS volume. Searching for the next extent of a file on an NTFS volume takes less than 1% of the time to read through the file extent at a size of 64 MB. For this reason, trying to bring together chunks bigger than 64 MB is not worth the effort in terms of CPU I/O and free space.
We also see complaints about the lack of a progress indicator. What’s so hard about showing progress?We talk about this in the Defrag FAQ. We don’t give a percent complete or time to completion estimate because defragmentation is non-linear. The first pass might not do much--Defrag tries to put the files together but there isn’t always some place to put them. If your volume has very fragmented free space, Defrag may only be able to consolidate free space during the first full pass. During later passes, Defrag may be able to defragment somewhat, but how much will vary for every defrag run. And during all this, moving files of different sizes takes different amounts of time. Instead of trying to show estimates of how much longer the defragmentation process will take, we worked to reduce the impact of defragmentation on your computer, so that you can use the computer during defragmentation. This benefit is gained by using low-priority disk and CPU I/O. This too is covered in our Defrag FAQ.
Are there any other improvements over Windows XP?Unlike Windows XP, Windows Vista does not require 15% free space (unless you use the –w parameter from the command line). If there is any free space at all, Defrag will make an attempt to defragment the volume.
Let’s talk about what we can expect for later versions of Defrag. What are you working on these days?Right now we are working on Defrag in Windows Server “Longhorn.” If you’re in the beta for Longhorn, you’ll have a chance to see what’s new in upcoming builds. We’re also working on improvements to decrease the amount of time it takes to defragment a volume and provide better defragmentation. Because the code base for Defrag is common for Longhorn and Windows Vista, the improvements we make in the server version will be added to Windows Vista SP1.
Bem pessoal, já vi em muitos locais usuários que estão utilizando já o Windows Vista, questionarem sobre
A Defrag/VSS question.... I've recently read some articles that under WS2k3, an NTFS volume with a block size of 4K (default) will experience corrupted shadow-copies when defragmenting.
If Defrag runs automatically under Vista/Longhorn, this seems like a serious issue. I'm assuming it's fixed, because I haven't noticed missing shadow copies from my Vista machines which are automatically defragged.... But it'd be nice to have some confirmation. ;-)
The block size of 4K will not cause corrupted shadow-copies with defrag.
It does tend to cause extra VSS shadow copies to be made, however. This is the case any time a lot of changes are made on your volume, such as adding or deleting letters from a Word Doc or cells from an Excel Spreadsheet. Defrag simply does a lot more file writing at one time than you do on your own, so it causes more of the copy on writes to happen. This will not corrupt your shadow copies.
There is a limited amount of space on your volume allocated for shadow copies, and once it is full, the oldest shadow copies will be deleted.
So, defrag can cause the deletion of the oldest VSS shadow copies.
Defrag does make an attempt when moving files to move them so that a Copy On Write does not occur to decrease the number of old shadow copies that are deleted. Also, if you have been running Scheduled Defrag weekly the amount of file moving per defrag operation will be less, so the Copy On Writes will be much smaller than for one big defrag of a highly fragmented volume.
Hope this helps.
Please, as a user, my highest priority is speed of defrag, not the efficiency. Please make it fast. Also, you can really make it defrag continously in the background, like Diskeeper does or at least make it defrag completely silently in the background while still using the computer.
Já não é um assunto novo para usuários do Windows Vista, falar sobre o Defrag. Porém, o que mais se encontra