XBIAN and powercuts

You could mount it read only, but I imagine there are a few wrinkles will need ironing out to get that to work smoothly. You could use a journalling file system but I guess that may produce a high rate of wear on the SD card. You could mount the problem areas of the file system in a RAM-disk and reload it from the SD card on each boot. Or you could use a USB power pack as a UPS.

Because flash memory is much more susceptible to corruption than hard disks.

If power is removed from a hard drive while its writing, one block may suffer direct corruption and there may be collateral damage if the write was part of a sequence which required an inode to be updated, a directory entry to be written, etc. That is about the limit of what can go wrong and, IIRC if you're using a journalling FS (ext3 for instance) if the lost write was to the journal no harm is done and if it was to an actual data file, on reboot the journal, which will be complete and secured on disk will be used to either back out or complete the update.

However, if power is removed from flash memory, much more serious things may happen. If a wear-levelling remap was in progress when the power failed, then the contents of the block being remapped may be corrupted and/or the mapping table may not be pointing at the appropriate block: either way quite a large slab of date (typically 4KB) is left in an inaccessable (because the pointer wasn't updated, or corrupted.

This is why, if your hardware relies on flash memory, its essential that you close any open applications and shut the operating system down before powering the device off. This same advice applies equally to anything you can think of that relies on flash memory and has a multi-step shutdown sequence which requires the user to manually perform more than a single operation:

- Raspberry Pis, WinCE-based PDAs, PNAs, and jail-broken satnavs running non-standard programs often require a multi-step shutdown

- cameras, mobile phones, iPods, non-jail-broken devices do not, but notice how long they can take to shut down: under the covers they're doing all this good stuff before powering off. However, if the battery dies before the shutdown is complete or you wrench the battery out during it and you can see the same sort of problems that you saw by powering off your RPi without first stopping programs and halting the OS.

Can't be done as long as the Linux system is installed in a single partition. Its quite possible to put /boot,/bin,/usr and maybe /etc in separate partition(s) and make then read-only, but you still need to put everything else in writable partition(s). That could be an interesting exercise on a Pi and you're still left with needing to come up with a way of applying system updates to those read-only partitions.

If short, the only simple way to do what you want is to make regular and complete backups of the SD card - but then of course you should already be doing that. You *are* already doing that, aren't you?

Make sure your SD card is mounted with the 'noatime' option. Otherwise every read will cause it to write back the 'last accessed time'. That generates lots of unnecessary writes.

Theo

I wish I knew, we've been simulating powercuts with using a relay in-line with the power input but have not managed to corrupt the SD card. We have however been able to induce temporary failure of the network switch port, the pi is connected to (it's a name brand I'd expect better of)

Serious corruption seems to be associated with wear-levelling, since wear- levelling involves adjusting the memory map that associates flash memory block physical addresses with the logical address map. As the number and timing of wear-levelling episodes doesn't seem to be easily predictable because this has to depend on the the wear-levelling algorithm, which is proprietary, and it will involve at least three blocks: wear levelling is going to involve swapping map entries for two or more blocks and the block containing the map, it follows that Murphy is deeply involved in the chances of memory corruption if you power off a device with running processes that uses flash memory.

The above BS aside, I've watched a friend yank an SD card out of a WinCE PDA and then power it off. The SD card was unreadable and he swore blind that he'd not done what I saw him do. The card was unreadable.

I've not (so far) done that and haven't (yet) corrupted any SD cards.

OTOH, I've lost count of the number of times I've hit RESET or power cycled systems using spinning rust (hard drives or floppies) to recover from program lockups and never corrupted disks by doing so.

Bottom line: I may be wrong, but are you prepared to gamble the valuable data you have stored on flash memory on that?

For me it's a disappointing conflict.

The Raspberry Pi is small, which lends itself to being installed out of the way, behind my telly. However, for that, it really needs to be bomb-proof.

It seems the only way to have it run XBIAN, and consistently boot for a long period despite powercuts, is to have a stockpile of pre-flashed SD cards to slam in fresh every time it goes wrong.

I could perhaps boot from SD and run the OS on spinning disc, but that undermines the low noise/power credentials.

Reworking the OS to keep parts of it mounted read-only is beyond what I can do in my spare time.

In all, I think I'm going to relegate the thing to the cupboard as a failed venture.

Do you not have a home server you could load the root drive from?

(I don't know much about it --- I just happened to be googling for things like this recently out of curiosity. There are other versions if you search for 'raspberry pi ups'.)

A battery would be just as good.

It's theoreticlly possible for wear-levelling to be done in a safe manner. There are some USB pen devices which claim to be safe from sudden disconnection so presumably use such techniques. I find myself wondering whether there are SD cards which are disconnect-safe?

Wear levelling essentially moves the content of one block of memory to another, and changes the pointer which locates it. A sequence such as

Copy data to new block Change pointer Mark old block as not usable

should avoid most of the problems. It does present a risk of the old block being reused if a failure occurs between the second and third steps being completed. I'm sure there are other better ways to do it.

It gets more complex if the block being retired is one of those holding the pointers, or the bad block list.

for

pre-flashed

Or just one cold spare. Can't remember if the crash FUBARs the card in the Pi or not.

The Pi UPS things signal to the Pi that the power has gone so it can shut down gracefully. Donno how a Pi would react to the slowly falling voltage of a dying battery. You also need a surprisingly large battery to keep a Pi up for say 12 hours, 6 AHr @ 6V. Power cuts here are either a short "blip" or 6 to 8 hours.

Alternatively don't run XBIAN try RaspBMC or Openelec. I run RaspBMC and that hasn't done a nasty when not shutdown properly. I've treid Openelec but that would lose touch with the mini wireless keyboard used to control it. Not tried XBIAN.

Or a "powerbank"