-1

Is it possible for a power failure to cause some part of a machine to write one or more random bits to a storage device?

Someone proposed the following idea to address such a risk: create multiple partitions on a single disk which together form a single RAID1 array; then assemble multiple such arrays together as another RAID device; use that to store the file system.

My guess is that this is expected to work since random data cannot be written to each RAID member simultaneously. Perhaps there wouldn't be enough residual power for the drive head to seek forward and write the same random data in each member partition. If all goes to plan, the RAID member with the bad data would be kicked out of RAID after the kernel reads from that block.

Such a setup would likely cause significant performance degredation due to excessive head seeking during all disk IO.

Is the threat of writing random data during power loss a real one? Are there other solutions to this problem?

EDIT: I should have been more clear. I believe the idea of putting a RAID1 on a single disk is a very bad idea. I'm asking about this because I heard of someone who thought it was a good idea and has implemented more than one system like this. I was hoping to put this idea to rest once and for all.

I was trying to figure out what possible reason they would have for this design, but I was later told that this was likely the result of a naive response to unplanned growth during a very hectic time.

I tried thinking of a situation where this might be useful, such as the idea of a payload for a linux filesystem modification getting corrupted, with the command to send the data remaining uncorrupted. I recognize that's unlikely, so it seems that this issue can be put to rest after all. Thank you @gene! : )

2
  • Too theoretical. Are you trying to describe a real situation?
    – ewwhite
    Sep 3, 2015 at 5:29
  • This just expands the window in which we're vulnerable to a failure. Consider two writes where we're screwed if one is completed by not the other. With the extra seeks required, the window between when the first one finishes and when the second one starts will be longer. So we're worse off. Sep 8, 2015 at 5:33

1 Answer 1

2

Is the threat of writing random data during power loss a real one?

For power loss: Random? Unlikely. Corrupted (half written data, etc)? Sure.

For a power surge: I guess there might be a possibility that random data might be written, but if the surge has reached far enough into the system to affect memory it's more likely you'll be worried about putting out an electrical fire and total data loss than a few bits of random data.

My guess is that... random data cannot be written to each RAID member simultaneously

RAID1 will attempt to write the data simultaneously, but being as your scenario has the volume on a single spindle perhaps this would happen. Huge if, I doubt anyone has tried this. And you face the possibility that corrupt data will be written to one side of the volume and nothing (or a smaller amount of corrupt data) being written to the other side.

Are there other solutions to this problem?

Use more than one physical drive in the RAID volume. :)

Resilvering/Scrubbing RAID volumes will typically find errors and attempt to fix, discard, or quarantine them.

Journaling file systems will help as well.

As @womble mentioned in the comments, file systems that have built-in checksum support would also help with identifying corrupt data.

You can also do things like provide adequate surge protection, have the server on an uninterruptible power supply, and use a hardware RAID controller with a built-in battery and cache (which would allow the controller to finish writing out the cached data when the storage becomes available again).

2
  • 1
    Checksum/FEC-using filesystems would be even better, from an error detection/recovery perspective.
    – womble
    Sep 3, 2015 at 4:06
  • Excellent point, @womble. I'll add that above.
    – Gene
    Sep 3, 2015 at 4:07

Not the answer you're looking for? Browse other questions tagged .