« Last post by smartbit on February 04, 2014, 07:17:54 AM »
Thanks for the response :-)
Your assumption is correct, there is no actual noticeable disk stress.
The log writes are about 2-4 Kb every several seconds, depending on the activity. So, by that, it won't be correct to say that it "stresses the system" really.
But anyways, 2-3 days after full defragmentation, 12 "prolasso.log*" files got 700-1000 fragments each, while the next most fragmented files (of the whole C:\ drive) are: prefetch, *.db, and other *.log files, which has less than 100 fragments each (and this is after a 2-3 days of a very "light" PC use: some web, some docs, etc.)
I once worked analyzing custom hardware device, and we used some SW tool to log various parameters and monitor device's memory for a long periods of time, which would result in a huge log files (up to GB). But the writes to the files themselves were performed every several minutes, each time writing few MB.
I don't know the exact technical details, but the guy who made this tool told me that his SW dumps the log constantly to the OS with some specific parameters, and then OS knows to cache it and perform write backs accordingly.
So, my understanding is that technically it is possible to accumulate 1-2 MB of the data for a while for a delayed write later (up to minutes).
Bottom line: If it can be done by modifying few parameters, without much effort/redesign, and by that decrease the write frequency and increase caching size, (making it as as option of course), it will be nice.
By the way, I noticed that log files' properties show attributes: ATI.
Does it mean:
A = ARCHIVE
T = TEMPORARY
I = Not content indexed
P.S. - BenYeeHua, the fragmentation I'm talking about IS the disk fragmentation, and I'm aware of the fact that updating (increasing the size, precisely) of the files will cause fragmentation.
Also, it's not completely true that it's impossible to force windows to save continuous space. It can be done by allocating space for a specific file size, and creating this file in advance. Modifying its contents later as much as you wish, as long as you fit inside the original boundaries. (It is (partially) similar to the way Page File being handled. And many other programs use this technique.)
But doing it here, may need some redesign of the current mechanisms here, and will cause too much trouble to go through for a not-so-important reason. Thats why I'm asking about a possibility to optionally decrease write frequency by more minor SW modifications.