The log files produce unnecessarily many fragments
Greetings from Switzerland
1 Like
Sorry for the problem. We will investigate and try to reproduce this on our PCs. What is this screenshot from?
For anyone who is interested, it is a common issue to have fragmentation of log files and other files that increase their size in small increments. This is a common issue with SQL Server files as can be seen if you search for something like “file fragmentation of log file”.
Is it likely to cause a problem for GlassWire users? I don’t think so as fragmentation has to get very bad or file sizes very large before this becomes an issue. But if it is considered to be a problem GlassWire could use the Windows defragmentation API to manage this issue.
GlassWire could pre-allocate space in the files and then populate it as required. However, I wouldn’t bother doing anything like this when there is the option of running a defragmentation task or using the API.
The rest of this post is just further info:
In NTFS, file fragmentation is said to cause problems at about 1.5 million fragments. The following discussion provides more info on this:
The operating system and file system usually determine how this occurs. Users have some control over this but the options are not suitable for GlassWire:
-
Increasing file allocation sizes. For example, increasing the cluster size on a disk reduces defragmentation at the expense of reduced disk space utilisation because the last part of a file doesn’t use the entire cluster so larger cluster sizes means more space unused for each file. This is not really an option for GlassWire because users have to do this when they setup their disk drive.
-
Storing log files and the like on their own disk. This is what you might do on a large database server but it is not really an option for GlassWire.
1 Like
Re manually defragmenting those files, I used Defraggler Free (free defragmentation program from Piriform, the makers of CCleaner) to defragment all the files in that folder (C:\ProgramData\GlassWire\service\stats) while the GlassWire.exe is not running.
I had no problem defragmenting the files nor afterwards.
there is:
Excellent point that the option exists to shift those files. 
Even so, for most users I doubt that it makes much difference to the fragmentation of the stat files.
The first reason is that, after further thinking about this, the intensive fragmentation is almost certainly the result of interactions between the various stat files. For example, stat file A is extended, stat file B is then extended, so when stat file A is next extended it writes as a file fragment, likewise stat file B when it is next extended, and so on. It would take a redesign of the GlassWire statistics process to be prevent this. But again, it is probably better to defragment the stat files instead of redesigning the statistics which could produce more bugs.
The other reason is why I originally said that using a separate disk (not a separate partition on the same disk) “it is not really an option for GlassWire”: most users are probably desktop end-users who don’t have a second hard disk drive with a larger cluster/file allocation size which would be needed to reduce the frequency of fragmentation (this occurs proportional to the increase in the cluster/FA size so double the cluster size and halve the fragmentation rate).
(Edited to change “log” files to “stat” files. I was thinking of log files generically but as Glasswire has a “Log” folder I need to avoid confusion with that.)
This is a screenshot from Defraggler
I have a SSD and it is unnecessarily burdened with write accesses, therefore it is also not sensible to perform a defragmentation.
I suspect that the .db before each transaction are opened and then closed again.