Question about Windows Disk Defrag

This might be a better question for a Tech Forum, but there’s probably at least a few Tech Ops Dopers out there, so here goes…

I have a Windows 7 VM which reboots every 5 minutes (it’s deliberate) (don’t ask).

I want to keep the file system defragmented, but the daily scheduled defrag couldn’t complete in the window between reboots. I disable the mechanism that reboots the VM, then ran defrag manually. It took 40 minutes +/-. Then, I ran it a bunch of times, and timed it. It ran consistently in under 2 minutes.

I think, if I leave it to run once daily, it will become sufficiently defragmented in a single day that it will not run in <5 minutes, so I scheduled the defrag to run at startup.

So, defrag will run every 5 minutes, or every time the VM reboots.

Aside from the obvious (rebooting a machine every 5 minutes seems crazy), is there any down-side to this I’m not seeing? I recognize there will be a slight performance hit, but I believe it will be negligible.

Thoughts?

Why do you think you need to defrag it that often?

As a PC tech, I can’t fathom why you would reboot every 5 minutes - it sounds absolutely insane.
Putting that aside (which isn’t easy), it would be EXTREEMLY improbable for much of anything to fragment your system in the couple of minutes between booting up and shutting down for rebooting.
Schedule defrag to run once a week.
After a week; Launch “Event Viewer”, click “Windows Logs”, click “Application” and then “Defrag” to see if it completed.

I too question whether the defragging is necessary. Or get a solid state drive (SSD) and forget about defragging.

In your case, I would be almost certain that the performance hit you take by running the defrag process almost constantly is much greater than any performance hit you would experience due to disk fragmentation.

I don’t think I need to, but I need defrag to be able to run, and with the constraint of the almost-constant reboots, I need to implement a method by which I can be sure that it will run, and that it will run in the time allotted.

Update: the reboots happen after 5 minutes of inactivity of a specific program, not every 5 minutes on the clock. So. Reboots less frequent than originally stated, but still many, many times per day.

Yeah. I agree. A little background: I’m the Director of IT for a software company. I’ve been a Systems Administrator for 18 years. So, as hard as it might be to believe, given the circumstance present, I really actually know what I’m doing. LOL

I think the amount of fragmentation occurring between reboots would be very little, but I can’t let it build up to the point where a defrag will take longer than the window available.

The defrag was not completing. It didn’t have time. I dug into the logs. The disk was extremely fragmented, but is much better now.

As stated in the OP, it is a VM, running on SAN. SSD’s just don’t figure into the equation. Yes, it would be possible to re-engineer the whole thing to run on a local disk (or something), but that just wouldn’t be practical, given the impact.

Alter your process so the 5 minutes of inactivity triggers first a defrag, *then *a reboot. Problem solved.

Your way and my way both achieve the same result.

We can’t answer you because you’re not giving us the parameter(s) involved.
What is ‘the time allotted’?!?
You can schedule Defrag to run a few days a week; select ‘weekly’ and then select more than one day (of the week).

The application in question is an NT4 Emulator that performs screen scrapes of data from forms, and reformats them and plugs the values into other forms. It’s a third-party software that’s a piece of shit, but there’s literally no alternative in the industry, and if we cooked up a home-grown solution, we’d be dealing with something very similar to what we have now, since the method of data extraction is the only one allowed by the company we get it from. The application we use was built explicitly to perform the task described, and as far as I know there’s nothing else out there that does it.

In short, it’s a nightmare. But, that’s IT for you. I didn’t build it, I just support it.

The only other solution I could see would be mounting the virtual disk in some other system and defragging it that way. If you have some time when the VM is always down, you could be sure to schedule it during that time.

You could also minimize defrag time by making sure all the changes you need to save are saved on one virtual disk or on the network, and then have another one that you just reset every time. With the network, you could just count on system’s built-in defrag schedule.

That’s all I can think of. If your way really doesn’t have any noticeable performance hit by defragging, that could work. I admit I never notice when my defrag runs from task scheduler. (I assume it has a fairly low priority.)

Edit: On seeing your response: I’m just curious. Why not use NT4 directly in the VM? And why do you need to restart all the time?

How have you have determined that fragmentation is negatively affecting the performance of the VM (therefore requiring defragmentation)?

I guess I’m missing something. Wait for your 5 minutes of inactivity, then start the defrag, wait for it to finish, THEN reboot.

And as your experiments have shown, as long as previous defrag wasn’t too long ago, you’ll get something close to your real goals, which are a system that’s up most of the time, fairly recently rebooted, and without a messy disk.

You already have an uncontrolled variable in there; the reboot duration. I’m just adding a couple minutes to it.

It seems like you only need to defrag once a day or so. If you set the task scheduler to defrag every six hours, and tell it to run on boot if the system was down when it was scheduled to run, you should get at least one complete run in a day, with less lag on your reboot.

If the machine is a VM, running on a SAN, then the idea of disk fragmentation at the OS level is almost meaningless.

Disk fragmentation is a problem primarily because the additional movement needed by the heads on the disk drive to read (or write to) a file that is not contiguous on the disk. But you’re running a VM, so your Windows 7 machine has no physical disk; there are no disk heads moving about at all. On top of that, if your VM is stored on a SAN, then the VMDK file (assuming VMware, but the principle is the same regardless of vendor) is spread out over a number of physical disks, because that’s how a SAN works.

So, regardless of the state of your Win 7 ‘local’ disk, the physical bits are strewn out across multiple physical disks, and there’s nothing you can do about that. Your disks will always be ‘fragmented’. But it doesn’t matter, because chances are your VM rarely has any direct contact with the hardware in the first place. All of your disk writes are going to the cache on the SAN, where they’re flushed to disk whenever the SAN gets around to it. And with your machine rebooting as often as it does, your SAN has also probably figured out by now that those bits are frequently used, and has them ready for you in its read cache, so you don’t need to wait for the physical disks to read any data either.

When you are running the defrag program on this machine, you aren’t actually doing anything at all to the data on the disk; all you’re doing is rewriting the master file table and metadata, so that certain bits that used to point to certain other bits are now pointing to different other bits. The actual bits on the physical disks, which is what defragmentation is supposed to address, stay exactly where they were.

Disk defragmentation can certainly be useful on a physical system, with a single drive (though even there it seems to be needed less and less with each iteration of OS), but on a VM on a SAN the defrag program is separated from the disks it needs to defragment by two levels of virtualization. It is simply impossible for it to do the job it was designed to do.

What you say makes sense from a logical perspective but I administer a number of VMware application servers as well and I defragment some of them daily and some of them weekly. On occasion, I have forgotten to update the defragmentation jobs on some of the less important DEV servers if I didn’t update my password on them after I changed it. I have looked at them months later (because they weren’t used that often) and noticed they ran like a 3 legged dog. Fixing the defragmentation certainly looked like it was doing something positive. It took a long time to run and appeared busy moving things back in order. Performance certainly seemed better afterwards as well. I suppose it could be a placebo effect because I didn’t take careful measurements but some of the worst cases went from terrible to good with just that step being the difference. I do know that our mega-corp SAN and server teams told me that it was OK to run frequent defrags but they asked me not to do it more than absolutely necessary.

To the OP, I am still confused when you need to reboot and defrag a server many times a day but I will take your word for it. There are other fragmentation tools available that work a little differently than the built-in Windows version. I have used Smart Defrag with good success on my own computers for example. It has a continuous defrag option that might work for you. That option just works quietly in the background and addresses the fragmentation continuously as it happens rather than running as a batch job. Something like that eliminates the need to worry about whether it finishes or not before a reboot because it doesn’t matter. It just does the work as priority allows and does not introduce any significant overhead to performance.

Any chance the OP is going to come back? I’m curious like other posters why the NT VM instead of just straight NT, and why not defrag (even if it may or may not be necesary) and THEN reboot instead of hoping the timing works out.