3

Isn't ext4 a journaling file system?

I'm running Raspbian.

testdisk recovered the partition, but the file system wasn't recoverable.

I had to use dd to restore a copy of the entire sd card.

Needless to say I lost several weeks of tinkering.

Is there a way to have a continuous backup of the root fs to a network location?

UPDATE

Today I started to have serious issues performing apt-get commands trying to re-install packages that got "removed" when I restored my Pi from an old backup. Checking the syslog I noticed the that the kernel was logging write timeout errors to my SD card.

Then grepping all the syslogs that I had available I can see that these write timeout errors have been happening silently for some time.

My guess is that I have been silently having writes to disk failing for some time and overtime this finally lead to my loss of the entire file system.

/var/log/syslog.5.gz:Oct 11 16:49:55 raspberrypi kernel: [ 1984.145023] mmc0: final write to SD card still running
/var/log/syslog.5.gz:Oct 11 16:50:05 raspberrypi kernel: [ 1994.147878] mmc0: Timeout waiting for hardware interrupt - cmd12.
/var/log/syslog.5.gz:Oct 11 16:50:05 raspberrypi kernel: [ 1994.149077] mmcblk0: error -110 sending stop command, original cmd
response 0x900, card status 0x900
  • Did you reboot your pi soon after making lots of writes to the SD card? Is it possible that you turned off your device before it was able to push all of the writes from its cache? – earthmeLon Dec 2 '13 at 21:11
  • No, the only thing unusual was that I moved my Pi to another room to connect the audio out to a stereo system. Perhaps that caused the voltage to drop on the system. – HeatfanJohn Dec 3 '13 at 2:46
5

Journalling is not a panacea for all possible forms of corruption. Based on reports here, the pi seems to be much more prone to corrupting its primary storage than a normal computer. My only speculation is it has something to do with the power shorting/surging and the SD card reader; while cutting the power suddenly is not a good idea or a habit to get into, it still should not destroy a filesystem with the frequency it gets reported here. In fact, throughout 15 years of pretty heavy ext2/3/4 usage, I've never irrecoverably damaged a filesystem on a working drive, or heard of such happening somewhere I've worked. Point being, it's the pi, or some pis, unfortunately.

testdisk recovered the partition, but the file system wasn't recoverable.

Don't use testdisk, use e2fsck. In general, do not try to do serious things with an ext4 filesystem using a Windows (or OSX) host. If you don't have another linux box, use a live CD.

I had to use dd to restore a copy of the entire sd card. [...] Is there a way to have a continuous backup of the root fs to a network location?

See my answer here for a more normative, easily maintainable method using rsync. It's not continuous, but it is quick once established, meaning you can do it every day or every hour easily (e.g. via cron)

  • 1
    FYI, I ran testdisk using Ubuntu. I will check out your referenced answers. – HeatfanJohn Dec 2 '13 at 1:29
0

The source of my problem was that I was overclocking my Raspberry Pi. According to the RPiconfig wiki overclocking can cause file system corruption on class 6 and class 10 cards.

I turned off overclocking completely and was able to perform extensive writes to the SD card using dd if=/dev/zero of=/tmp/test bs=4M count=1024

With overclocking turned on I would get a write timeout error a few minutes into the write test.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.