The New Hotness

I iterated this sequence three times before I caught on:

• ssh into Raspberry Pi
• Edit /etc/rc.local, save changes
• Reboot, observe the changes had no effect
• cat /etc/rc.local shows no changes

Then I:

• Edited / saved
• Listed the file to verify the changes
• Rebooted, observe no effect from changes
• Listed the file again: the changes were gone

Huh.

It turns out the card went read-only without warning, so I was displaying the contents of the file cache buffers after the edit, not the data stored on the card. Rebooting started with empty caches, read the previous file contents, and behaved accordingly.

The F3 utilities now live in the Ubuntu repository and no longer require compiling from source. The result:

sudo f3probe --time-ops /dev/sdb
F3 probe 6.0
Copyright (C) 2010 Digirati Internet LTDA.
This is free software; see the source for copying conditions.

WARNING: Probing normally takes from a few seconds to 15 minutes, but
         it can take longer. Please be patient.

Probe finished, recovering blocks... Done

Bad news: The device `/dev/sdb' is damaged

Device geometry:
	         *Usable* size: 0.00 Byte (0 blocks)
	        Announced size: 7.35 GB (15415296 blocks)
	                Module: 8.00 GB (2^33 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 164.4ms
 Operation: total time / count = avg time
      Read: 107.1ms / 4098 = 26us
     Write: 56.6ms / 2049 = 27us
     Reset: 0us / 0 = 0us

That card has been kicking around for a while and started out as a no-name generic in some random gadget. Of course, those fancy Sony MicroSD cards weren’t shining examples of durability, either.

I’m mildly astonished the streaming player worked perfectly with what amounts to a read-only filesystem, but that’s what caching is all about: there was no need to write the data to “disk”.