Meta

Tag: BG Defragmentation

In earlier postings, I had written, that my Windows 7 computer ‘Mithral’ had become unstable, and that this was related to the fact that I had set up background-defragmentation using the 3rd-party, commercially-paid-for Application named “Diskeeper 2011″. The reason for this idea was the observation, that crashes seemed to take place only during times of the night, when I had Diskeeper configured to do its BG-defrag, and while I was not making any active use of that computer.

In connection with this I had observed, that sometimes a Windows computer can get into a state, where the session does not survive a defragmentation, until a ‘Check-Disk’ is run, even though in my case I had run a Check-Disk, and the problem persisted.

What I have found instead, was that simply updating to a new version of Diskeeper, which requires to uninstall the old version first, seems to have solved that problem. I can think of two reasons, why it might have done so:

There might have been some FS Corruption, but the type of background-scan which version 2016 of the software performs, may be sufficiently improved to correct that, without causing a crash, or

Diskeeper uses some version of the Visual Studio C++ Run-Time Library, and while I was installing “Visual Studio 2015 Express”, I also did update a certain ‘MSVCRT’ to the latest version. But, since Diskeeper 2011 was not an up-to-date Application version, it might itself have gotten into trouble, from depending on the latest MSVCRT version. So, an up-to-date Application-version, may also be able to make full use of an up-to-date library version.

Both mentioned versions of Diskeeper have approximately the same features, including to perform ‘Fragmentation-Prevention’, by caching files that are being written to the HD for longer than Windows would normally do so, in order to be able to write contiguous output blocks, and including ‘Background-Defragmentation’, for which we can schedule times of day or days of the week we want it to happen.

One fact I find odd under Windows, is that no effort is made where the user can see it, to distinguish between ‘Fragmentation’, and ‘FS Corruption’, the latter of which can also be called ‘File System Inconsistencies’. The idea in the minds of Windows software developers seems to be, that whatever we have, we have, that being, whatever is linked.

But a deeper fact which I know about Windows, is that if an efficient defragmenter is let loose on the File System, and it encounters actual FS Corruption, it will cause Windows systems to crash – to do one of those nasty reboots which the user did not tell them to do. This has led to some people not being able to get through a defrag, before the computer would crash, until those users ran a File-System Check, between reboots, using ‘Checkdisk’, which solved their problem for them.

When either version of Diskeeper is told to do a manual defragmentation, it does not go as deep, as one of its scheduled, Background Defragmentations go. This was a major reason for My Previous Posting.

What I have learned, is that the 2016 version of Diskeeper, does a much more thorough job of cleaning up the File System, even during the Background Defragmentation, which its software company no longer touts as a major feature. The software company mainly touts the Fragmentation Elimination feature. But BG-defrag having taken place successfully last night, and having produced the report it did, makes me confident again, that it was able to find FS Corruption which neither its 2011 version, nor Windows Checkdisk, were able to recognize. And so I may be able to keep the present O/S installation on ‘Mithral’.

In fact, having been able to perform heavy computation continuously from 13h00 yesterday, until 4h00 this morning, while Diskeeper 2016 was installed, and then allowing this software to do a BG-defrag, also impressed me about the idea, that at least the H/W seems to be quite stable.

Dirk

(Edit : ) It would not be obvious how “Fragmentation-Prevention”, would reclaim those 13,184 blocks. But according to the System Software I studied, there is an answer. There exists Internal Fragmentation, and External Fragmentation.

I have been using a powerful Tower-PC named ‘Mithral’, on which I have installed Windows 7 Pro, and which has an 8-core CPU, threaded as 4. This computer was first installed in 2011.

This computer had special software installed, named “Diskeeper 2011″, which continuously defragmented my Hard Drive, but in an effort to be able to save the HD even in the worst-case Fragmentation / FS Corruption scenarios.

‘Mithral’ has developed the habit now, of repeatedly going into an unresponsive state, overnight, which is also the time when it has been configured to do its background defragmentation.

The fact that it never freezes during the day, but often now, overnight, suggests that the problem may lie in File System Corruption, which can lead to fatal errors, if defragmentation encounters it under Windows. I have run a ‘Check-Disk’ on it, but doing so has not remedied the problem.

However, one apsect of this problem which puzzles me, is the fact that so many defragmentations have run successfully, without immediately tripping over any FS-Corruption issues. This casts doubt on the idea, that the problem may be due to FS Corruption. What could also be happening, is that Diskeeper 2011 may no longer really have been compatible with the most-currently updated Windows 7.

And so, because these hangups seemed to be taking place during a time when Diskeeper 2011 was running, what I have done for now, is to uninstall that, and to install the most up-to-date version, that being “Diskeeper 2016″. As usual, I am able to tell Diskeeper to defragment the whole HD without any immediate errors. But now I will have to wait and see, whether continuous background-defragmentation, using version 2016 of the software, is ultimately more stable.

Because a computer which crashes every second night is not really supportable, I might eventually need to wipe ‘Mithral’, and to make an attempt to resurrect it, using some version of Linux. If I succeed, at least I will still have the benefit of the hardware.

There is some chance, however slight, that the problem is not really FS Corruption, but some sort of Hardware problem. If that should turn out to be the case, then even with Linux on it, this computer will still crash and/or be unstable. This will be even more sad.

To prepare for eventually reinstalling, I will need to migrate critical data off it, to my other computers, with a depth I have not had to do so in before. This will not be one of those cases, where I can just wipe the HD and kick the present O/S off it on a whim. I need to think this through, as far as data is concerned.

This is my last remaining Windows computer. There exist certain services under Windows, that I cannot duplicate under Linux, and I might need to get by without those.