Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I noticed that our code is writing our configuration files to disk every time the program exits, even if the configuration has not been altered. It takes less than 0.25 seconds to write out all the configuration so the user's don't actually notice any delay on close.

However we are trying to figure out which is more reliable over the long term. Reliable is reading the exact same bits as were written. Long-term would be running the program 0 to 10 times a day for 3 years.

We are definitely not experts in disk drive performance, so any clues as to where to look for answers would be appreciated.

share|improve this question

closed as not constructive by mdpc, mgorven, EEAA, Ward, Khaled Feb 20 '13 at 8:03

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

why would the configuration details change in between read and write? If the config cannot change on disk between read and why? what would be the benefit of writing the same information back? – drone.ah Feb 19 '13 at 22:42
RAID controller? Hardware configuration? OS? – ewwhite Feb 19 '13 at 22:46

If something happens at the wrong moment while overwriting, the configuration file could be destroyed or lost. This (with today's filesystems microscopical) risk doesn't exist if nothing is written.

share|improve this answer
Actually, this is why programmers with any sense don't just overwrite critical files without making a copy first, or keeping a "last good config" around. No need to worry about write corruption when you make sure to hold onto the last file that actually worked. – HopelessN00b Feb 19 '13 at 23:19
Yes, but the renaming is also a (microscopic) risk. If there are changes, keeping the old one around is just common sense. But only replace if there are changes (so that if you keep, say, 5 worth of old ones, you don't get just 5 copies of the same). – vonbrand Feb 19 '13 at 23:24

Why are you reinventing the wheel?

You use what has been used since before I was born - a bit or boolean flag when a change is made to the configuration to indicate that there are changes to write to disk. There's even a name for this, the "dirty bit" or "dirty flag" (and it happens in memory, no disk write required).

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.