[Nook Color Android Development] steven676:
Yes -- in your SD card's flash translation layer.

To make a long story short: those are exactly the symptoms of a bad FTL corrupting a filesystem after a crash or power loss.

The ext* family of filesystems typically does reading and writing of data in "blocks". In any filesystem larger than 512 MB or so, the block size is usually 4 KB, though 1 and 2 KB blocks are also supported. This scheme works very well on spinning-platter disks, where the smallest independently updatable unit of space is typically a 512-byte sector (4 KB in newer "advanced format" drives). Unfortunately, on flash, the smallest unit you can read or write to at once (a "page") is typically in the neighborhood of 16 KB, and the smallest unit you can erase (an "eraseblock") is around 4 MB -- or ~1,000 ext4 filesystem blocks!

To allow usage of filesystems designed for traditional disks on flash, devices such as USB flash drives and SD cards ship with a "flash translation layer" which sits in between the raw flash and the system. The FTL typically manages the demands of small-block updates by writing the new data to a separate eraseblock, then marking the old data obsolete. To prevent a situation where a bunch of mostly-empty eraseblocks still have some current data hanging around in them, and also to try to balance "wear" on the flash (caused by writes -- one eraseblock on current parts is typically good for about 10,000 write-erase cycles) over the entire storage, the FTL will periodically decide on its own to move data from one eraseblock to another; this sort of consolidation can also be triggered by an operation performed by the system.

If the power is interrupted during one of these grand data-shuffling operations, though, you could end up with a full eraseblock or more of garbage in the filesystem -- which, as you've sadly discovered, is generally not a recoverable situation (it's probably not reasonable to expect a FS to be able to shrug off a thousand blocks suddenly disappearing out from under it). The higher-quality FTLs in drives from top-tier manufacturers (we swear we're not being paid by SanDisk! -- at least when it comes to SD cards, it's difficult to find other brands with good FTLs) are implemented to avoid this problem using techniques such as journalling.

How do vendors of cheapo USB flash drives and SD cards (you rarely, if ever, will have these problems with an SSD) get away with shipping bad FTLs? The vast majority of such drives are formatted with the FAT filesystem and are used to store relatively large files which are accessed one at a time; these characteristics combine to mostly hide the effects of a bad FTL, since FAT is super-simple and has relatively large block sizes.

None that I'm aware of. It's possible that there's a bug fix somewhere in between 3.0.8 and 3.0.71 upstream that might be relevant -- but any such bug would be most likely to corrupt individual 4 KB blocks of the filesystem, not a huge chunk all at once.

None that I know of -- that said, we don't get all that many reports of crashes with stack traces, so it's hard to say.

Reboot-after-panic is a different code path than a regular reboot -- it's possible the hardware is being configured to boot the eMMC after a panic. If you have the stock software installed on eMMC and are running CM off the SD card, that would result in a panic while running CM causing a reboot to stock.