Forums Feature Suggestions Buffered log writes to disk

A suggestion for a future version of mIRC would be to buffer logs to memory before they are written to disk, and then flush the buffer to disk every few minutes, perhaps even every half hour, or after whatever duration a user chose.

The issue with current functionality is, if you turn logging on, new lines from the server result in the drive heads (the vast majority of the time) needing to move to write the line to the appropriate file. This dramatically increases the number of head movements, thereby shortening hard drive life. You can imagine the effect of multiple active channels!

While difficult to prove, the method by which mIRC logs to disk at the very least contributes to the dramatically lower-than-normal life I've experienced on multiple hard drives over the years.

If the logs were buffered to memory (much like DeadAIM does for AIM conversations) and written to disk less frequently, I would have to argue that you would serve to increase the life of users' hard drives, at least a bit!

The OS does disk caching itself, you want to save the drives, buy some more ram, personally i wouldnt care, drives are pretty cheap these days.

I'm sorry but that's just wrong on every level. I hope all your posts on this board aren't as careless.

Yes the OS supports caching, but it certainly doesn't cache more than a second or so of writes. Data doesn't just sit in cache for minutes on end, it's written to disk as soon as the drive is ready. While buying more RAM will certainly decrease the overall amount of disk accesses, it most certainly won't alleviate any writes to disk related to mIRC logging. While hard drives are relatively cheap, it takes time to rebuild a system, and the vast majority of backup policies for personal computers have the tendency to lose data, not to mention the cost of downtime.

Cost of downtime? You aren't chatting at work, I hope.

Inserting a hard drive into a computer is quick and very easy. Copying data over takes time, but can be done very easily (set it up overnight). You know ahead of time if the hard drive is going in most cases related to wearing out from use as you are mentioning, so you can leave it in and copy stuff easily without any other software needed. Or, you can ghost it and that doesn't lose data unless you don't know what you are doing. I run 4 drives in my computer and have replaced only two from dying over the past 15 or so years. My computer is online 24/7 and connected to IRC 24/7 in multiple channels (usually 5 at all times) and I log them. I have no significant hard drive deterioration caused by logging.

I personally wouldn't want to see mIRC write logs every half hour or whatever. In large channels like you mention, the cache could be considerable. Yes, text writes quickly, but it can still cause a small hiccup in CPU usage from large channel writes. That isn't a good thing when playing a game to have a game freeze for a split second every half hour. A split second may not seem like much, but in some games, it can be the difference between life and death.

In your opion you mean to say that its wrong on so many levels, but i didnt really see anything that showed it as such.

Caching is so there is fewer diskwrites/reads reads are if anything as important as writes especially in logs, since the hardware (the level accessable to the OS) doesnt write bytes to disk one by one, but rather in blocks, This means writing to the end of the log takes a read of the last block, which is then added to and rewritten. Thus Data Does sit in the cache for hours sometimes (but not unwritten data). You cant say what well occur when you get more ram, since the OS pools ram for its own use, a larger ram pool can drasticly or not at all, change the writting habbits of the OS to a drive. Rebuild time is maybe 10 mins on a data drive (excluding copying which you just leave to it) and on a system drive is maybe 20 mins & copy time without software assistance and 20mins alone with it. Just cause your backups (or those you have seen) are shonky Doesnt mean everyones are.

Now id like to mention about the actual idea of "to buffer logs to memory before they are written to disk", while this might sound all nice and dandy, lets take a look at what happens to ram in the OS, unless you specificly inform the OS not to swap ram out, then its happly gonna take your buffer and swap it to disk when it wants the ram for something else, then your ram logs need to be written to again so its gonna swap something else out and bring them back in, add to them then likely swap them out for something else again, finaly the ram buffer writes gonna occur and the OS is gonna read them back in, and write them out to file. Total disk writes saved in the process -200%+ (i would guess the + is a large + also).

How do we reduce this swapping? Buy some more ram! And if your drive ever starts to die after years of brutal writes what do you do? buy a new drive!

PS: dont be saying tell the OS not to swap it out then, since for something as unresourced as a buffered log to save diskwrites that would be arogant at the best, and if it was then the the buy some more ram becomes bold and flashing as well, since thats gonna do nothing but waste resources in far shorter supply than a hdds life span.

While perhaps Mixx's reasoning isn't the most agreeable with, I can't see the harm in the addition of this if it was implemented sensibly. e.g. a 32 or maybe 64 kilobyte cache tops per log.

This wouldn't provide a 1/2 hour between writes (the possibility of data loss during that period makes it nonsensible). It will however definitely reduce the frequency of writes.

If your OS is having to swap such small amounts of memory most times mIRC tries to read it, then the problem isn't with the OS or any software but in the physical RAM level being insufficient for your needs.

I have an mIRC bot on 5 active channels, and after running 3 years it is still going...

I would like to see a small cache for logging (64K max), because I agree that constant little writes can lead to excessive wear on a hard drive in some cases. A 64K cache for logging would solve this...

About extra CPU usage - so what? mIRC is already one of the least CPU intensive programs I run. It even takes less CPU than Yahoo Messenger, AIM, and MSN Messenger do most of the time.