Power failure should be considered as a scenario to implement?

Question

Do you think that power failure is a scenario to implement?

At what time that scenario should be taken into consideration? If power failure will cause some data loss so do you care about it ? if(IsImportant(data)) ... else .. ?

What do you think If our application doesn't work anymore even power failure scenario shouldn't be fault to consider if power failure broke the application permanently ? So we have to consider these situations always ?

Can you suggest pragmatic approaches for power failure scenarios ?

when you say electric loss, do you mean power cut? As in all the power goes off? — Matt Ellen, Jun 07 '11 at 12:42
It's usually called "power failure" or "power outage", then. — ZJR, Dec 14 '11 at 01:37
Read Hard-assed Bug Fixin' by Joel Spolsky (http://www.joelonsoftware.com/articles/fog0000000014.html). In short: find out what it costs to support a power failure and find out what is costs to not support that scenario. — jao, Dec 14 '11 at 07:37

score 7 · Answer 1 · answered Jun 06 '11 at 20:32

7

I would say that you should never have anything on the software side break permanently under any scenario. That's not acceptable behaviour in this day and age. Obviously you can't control how hardware is going to deal with power loss, but that's not your problem either.

30 years ago, when everyone was using mainframes, code was written that optimized RAM usage by writing everything to non-volatile storage, so a certain amount of breakage was inevitable. But now? You have too many options.

answered Jun 06 '11 at 20:32

Satanicpuppy

6,200

1

Can you list some of those options? – Adam Lear Jun 06 '11 at 20:43
And, forty years ago, mainframes used core memory, which isn't volatile. – David Thornley Jun 06 '11 at 20:54
1

@anna: Transactional databases? Journaling filesystems? Lots of good stuff. – Satanicpuppy Jun 06 '11 at 21:07
3

@david: Well, at 3000 dollars for 32k of memory, there usually wasn't a whole lot of it. In my experience, programs on those machines wrote to tape/magnetic media as fast as they could, and that memory/storage transition was vulnerable to power failures. – Satanicpuppy Jun 06 '11 at 21:14

score 4 · Answer 2 · answered Jun 07 '11 at 01:18

When time that scenario should be considerable?

When your contract says your application works in spite of electric loss.

If electric loss will cause some data loss so do you care about it ?

No. Only when the contract says it works with electric loss.

If you're worried, simply say that your program doesn't work when the machine fails to work correctly.

What do you think If our application doesn't work anymore even electric loss scenario shouldn't be fault to consider if electric loss broke the application permanently ?

If electric loss damages files on the disks, that has nothing to do with your program. The OS failed to maintain disk file integrity and your program was damaged.

Unless your contract says -- very specifically -- that you will guarantee to work through electric loss, you should do nothing.

So we have to consider these situations always ?

No. You consider them never.

File system integrity is part of operating system. Not your application.

Unless your contract says -- specifically "This application will not damage files during electric loss" -- don't worry about it.

If you want to worry about it, then you must write an operating system which guarantees that no file damage will occur during electric loss. After you do that, then you must invent a disk drive which guarantees no damage during electric loss. Then you must invent a power supply, cooling fan and rack which guarantees no damage during an electric loss.

After you have invented all these new, wonderful things, then you can write your application which handles the electric loss scenario.

+1, although in some industries (MRI, robotics, weapons) I would say that electrical disruption is a concern. But then again, a customer would be pretty dull to not mention that they want some sort of fail-safe. — Job, Jun 07 '11 at 02:46

score 2 · Answer 3 · edited Jun 07 '11 at 11:56

2

One simple rule: Commit any change to a permanent storage as soon as possible.

For instance, one thing that I really dislike about Visual Studio is that it saves the workspace only upon closing the solution or the IDE. I've had a few situations when my machine crashed and therefore the last situation in the workspace was lost. When opening the solution again I was presented with the configuration from the last time.

Therefore: commit change as soon as the user has made it. Don't keep it in memory until the end of the session.

Also don't keep files open for a prolonged period of time. Open them when you need them then close as soon as you've done with them. An unplanned hard shutdown could damage the open files.

edited Jun 07 '11 at 11:56

ChrisF

38,938

answered Jun 06 '11 at 20:47

I'm pretty sure "Save All" saves the solution file, though I don't remember an obvious indicator for whether the solution has changed or not. "Workspace" sounds a bit Visual Studio 6 - are you using old software, or just old words? – Jun 06 '11 at 21:46
I'm using "old words". And you missed my point. Pull the plug from your computer in the middle of the work and see what happens. – Jun 06 '11 at 21:48
@Developer Art - I think you're missing my point. Save All is just as easy (often more so) than saving files individually, and doesn't need you to close a solution file or exit the IDE. It doesn't just save your source code windows - it saves the solution and project files too. Unless you're claiming it doesn't (I haven't had a chance to check in the last few days - mostly running Linux). I should have given you +1 for the answer overall - I have the save-regularly habit too - sorry for that oversight. – Jun 07 '11 at 12:04
@ChrisF - I preferred the answer before the edit - the idea of communicating with the spirits of your dead edits. – Jun 07 '11 at 12:14
@Steve314 - you can always roll it back ;) – ChrisF Jun 07 '11 at 12:16
@Developer Art - on reflection, I am probably missing a point. For some people, it would be nice if the solution file auto-saved after every change. But not for everyone. Based on source code files (and a time when I had to use a machine that crashed frequently), I know that most recent autosaves tend to be at just the wrong point - e.g. just after a cut, but before the paste. For expert users, a manual save point is usually more useful, so a manual save habit is often better than auto-saving - though for non-expert users and other kinds of saved data, you're probably right. – Jun 07 '11 at 12:35
@Steve314: Steve, I do have a habit of saving files but I do it for individual files. I have not developed a reflex to click "Save all". My files are not damaged after crash, only the last state of the IDE desktop (which files are opened, at what position, bookmarks etc.) is lost. Not a big deal but an inconvenience. What I'm proposing is that the IDE regularly saves the desktop as well. – Jun 07 '11 at 12:42
@Developer Art: Long ago, I got into the habit of saving whenever I stopped to think. It isn't nearly as important now as it used to be, computer systems being more reliable now, but it's still not a bad habit to have. – David Thornley Jun 07 '11 at 15:17
@Steve314: He means the .suo file. – ThomasX Dec 14 '11 at 09:05

score 1 · Answer 4 · answered Dec 14 '11 at 02:37

Loss of power implies that by default your software will stop working. You have a couple of choices, either accept that data loss is likely, or code your software so that data loss cannot occur.

If you assume that you need to preserve data at all times, you are still likely to encounter the possibility that some data loss may still occur. For example, your code begins a write operation (eg: to database, file, etc...), and before the operation completes, the power is lost. Nothing you can do without ensuring the hardware has some means to signal your software to indicate that power will fail, and to then provide enough time for your software to commit any changes to some sort of storage. The other option would be to cache all volatile changes to a data store every time something changes. This may have an impact on your program performance, which probably also needs to be taken into account. IMHO however, this is a bit of an overkill scenario, but do-able if absolutely required.

Ultimately you need to look to your requirements, and to your product design. You really should get feedback from the customer about such requirements also. If near 100% data retention is essential, then design your product to suit, and if not, I wouldn't really worry about it.

score 1 · Answer 5 · answered Jun 07 '11 at 02:36

If you are providing a solution, and not just writing some code, you have to consider many things.

Are you writing software or delivering a system? This question is intended to be rhetorical.

If you are delivering a system, It operates in an environment.

There are interoperability requirements. There are maintainability requirements (Upgrade, Configuration Validation, Commissioning & Decommissioning).

There are performance requirements (fast enough to be worth using)

There are reliability requirements. [In the embedded space, power outage is a common occurrence.]

I used to ask a power outage question when I was interviewing for software engineers to work on critical systems.

A journaling File system and TWO copies of critical, files that get written to covers a multitude of sins.

If the power goes out, your system should act appropriately. If the OS is capable of supporting all your reliability requirements, that is great. If the Hardware is capable of supporting all your reliability requirements, (One good answer to my power outage question was "Get a UPS") that is great.

Sometimes engineering has to happen to make reliability.

Customers often fail to specify things in requirements, then might not pay until the product fits their initially un-stated requirements. Requirements elicitation and requirements validation can make life much easier for software engineers. Look at the (FREE!) CMMI standard for an idea of what those activities might encompass.

If you are a programmer TL;DR Someone else does it.

I read the whole lot, but there are passages where you sound a lot like Confucius. — ZJR, Dec 14 '11 at 01:46

score 0 · Answer 6 · answered Dec 14 '11 at 01:28

This entirely depends on what you are writing and who you are writing it for

I have worked on things where this is not only required, but part of the default requirements list for ALL projects, I have worked places where they don't care at all, and I have worked places that the consider that purely an infrastructure issue and not an issue for developers as many of the other answers imply.

If you are working on something that must have absolute transactional integrity under any circumstances it generally involves the developers to some degree because there are going to be some choices that are forced to make certain that things are committed to disk rather than written to buffer for example.

Andy points out the most interesting case where odd failures can be used to circumvent a security or audit policy. I have worked on a few systems that actually worried about this sort of thing as well.

Usually you get one of the following answers for this questions:

doesn't matter, just try to make it easy to restart clean (think of paint)
it matters a little, don't corrupt anything historical, but if you loose some data since the last disk commit or transaction log backup you are probably ok (think of visual studio)
it matters quite a bit, make certain that you commit every record to disk, and probably to a log before moving to the next step, also get some decent UPSs and maybe a generator (think of financial transactions)
it is the only thing that matters more than functionality, add functionality that locks the system in a fail-safe or fail-secure mode at the first sign of disruption, buy even more/bigger UPS & generator, get a collocation site, use BGP, get a D/R site etc. etc. etc. (think security systems, banking backends, etc)

The step from the 3rd to the 4th tier is a HUGE step in many systems, but the simplest example I can think of is in a physical access security system: If the power is out, and your UPS is down to it's last 30% your code needs to decide which doors to lock completely, which doors to unlock completely and where to unload the elevators before the power fails completely.

score 0 · Answer 7 · answered Jun 07 '11 at 06:36

I once wrote a program that created an output disk. The user was only allowed to create a certain number of output disks. We counted the disk when we STARTED writing to it.

The only think QA could find wrong was "If you turn off the power while the program is running, it does the wrong thing."

I responded that we had indeed considered that scenario, and decided on counting the disk when we start writing. Otherwise the user could deliberately turn off the power while writing the disk and gets a free (unounted) disk.

So yes, in any case power failure should be considered when developing an application. You could argue that, hey, it's a power failure so we failed, OK? But remember that the user can induce a deliberate power failure.

Power failure should be considered as a scenario to implement?

7 Answers7