A Possible Oversight on my part, Concerning FS Corruption

One of the facts which regularly concerns me about Linux, is that we Mount a File System so that we can access its files, and that we Must Unmount it at the end of any Kernel-Session, before we can power down or restart the machine, and that failure to do so results in FS Corruption.

But there is a thought which has only occurred to me recently, about how that might not translate correctly into Windows. It could be that under Windows, there is no hidden Mount or Unmount procedure, when we boot the computer or shut it down. In the past I had always assumed that this step does exist, but that Windows keep it hidden in the BG.

If Windows has no analog to this, then the problems I was describing in This Posting, may simply be due to a weak, dodgy hard-drive on the computer I name ‘Mithral’, purely in how it functions as hardware.

Also, I should next take steps to take a closer look at OS/X, which was originally derived from some form of UNIX (‘BSD’), but which may also have done away, with any sort of Mount or Unmount taking place in the BG.



Mithral Seems To Be Stable Again.

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.

This situation had led me to the possibility, that I might have to reinstall a new O/S onto Mithral.

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:

  1. 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
  2. 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.



Diskeeper 2016 is definitely Better Than Version 2011 was.

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.


(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.

Continue reading Diskeeper 2016 is definitely Better Than Version 2011 was.