How is the Beagle Board running Angstrom Linux at tolerating hard
poweroffs? Of course of interest are the filesystem, the integrity of
the SD card itself, and the hardware.
Actually, it is not a Beagleboard problem, but a combination of filesystem type and flush/sync frequency.
A multitasking operating system is almost always reading or writing files somewhere. You may try the command lsof to see the list of files and sockets; when the fourth column (“FD”) contains a number followed by “w” or “u”, then it means that there is a file in “open” status for writing or updating. The number of them can be astonishing (I see more than 1000 w/u on my old Ubuntu desktop system).
Every time you power off, the system has no time to flush “write” buffers. That is, a “write” operation could be aborted in the middle of updating the file allocation table (no MSDOS pun intended), thus leaving discrepancies between the actual data on disk and the actual directory hierarchy data (larger discrepancies if the “disk” has large “blocks”, like memorycards or flashmemory). “Repairing” it means checking allocation structures trying to guess what is missing (possibly losing files). Most Linux systems just check and repair at every reboot, requiring user input only for the most dramatic cases.
You may want to go back to the stone age using a filesystem with “sync” option (that is, return control to the program only after completing/syncing a write operation), but this will make the system slow and unusable (and will overstress the disk with too much “write” operations: remember that memory cards life depends on “write/erase” cycles: with different memorycards your mileage will vary). Delaying write operations means that the operating system can sort/optimize/reduce them (for examples, if modifying ten files in one directory, the directory could be written once instead of ten times) and complete when there is less CPU stress.
A possible solution could be building and tuning a complete Linux system with read-only root (a hard poweroff won’t damage the filesystem), variable data in tmpfs (a hard poweroff won’t leave broken directories), and read/write storage on a possibly “sync”-mounted partition (that is: only files that need to be frequently written/deleted go there, to minimize damage). This is quite an expert task.
A simpler solution, if the filesystem is small enough, is using a large RAM-disk at boot (and the read/write user data storage on a SD). The Beagleboard xM has plenty of RAM. If you don’t need to use Firefox 4 with lots of open tabs, you may consider it.
That said, you sholdn’t call it an issue. Since December my xM is happily running in the car of a coworker, off its original microSDHC on which I installed Ubuntu 10.10. It has an internet connection (UMTS USB key) and a GPS to tweet its position from time to time. This means it has a “hard poweroff” everytime the motor stops (thus, at least 20-30 times per week). It does many disk writes because it starts a full Ubuntu Unity desktop and auto-updates Ubuntu packages daily. This means that the microSDHC is quite stressed with “writes”. To date, it never had problems. Some weeks ago I bought and prepared another 4Gb microSDHC, but it appears that the microSDHC which came with the xM is far from dead, and all of those “hard poweroff” did never require anything more than boot time automatic check/repair.