I've recently bought a cheap mini-PC with an ARM SOC and a 8GB builtin flash memory.

I've flashed the Ubuntu Trusty image on the internal NAND but after a while i've started noticing random file corruptions, so i suspect the memory has some defective blocks.

So now i would like to:

  1. do a full scan for bad blocks on the NAND and mark them so they won't be used anymore (the filesystem is ext4)
  2. get a list of files currently stored in defective blocks so i can reinstall the deb packages affected

The scan could be performed offline, because i can boot another Linux instance from the SD, but it must be non-destructive (it will restore the block contents after the test so i don't have to reinstall the whole thing again)

  • 1
    For a magnetic HDD, it'd be e2fsck -c -c /dev/whatever ... but I doubt that's right for flash, as flash normally moves blocks around, etc. – derobert Jun 3 '15 at 2:16
  • Do a RAM test. I don't think there's anything like memtest86+ for arm but there are a few tools. – Gilles 'SO- stop being evil' Jun 3 '15 at 21:07
  • @Gilles do you think a defective RAM chip is more likely? I've never experienced random program crashes btw... – eadmaster Jun 4 '15 at 12:51
  • @derobert: the fsck -f -c -c /dev/nandX command seems correct, but i am not sure how to get the list of affected files... – eadmaster Jun 4 '15 at 13:16
  • File corruption is a common consequence of bad RAM. Depending on what you run, you may not have experienced crashes or not interpreted them as being due to the RAM. What kind of corruption are you seeing? Corrupted bits in a given position (e.g. always the 0x20 bit of the 3rd byte in a 16-byte block) are telltale signs of bad RAM. Bad RAM can also cause whole blocks to be bad (when a pointer was corrupted) but this can have other causes. – Gilles 'SO- stop being evil' Jun 4 '15 at 13:33

The fsck -f -c -c /dev/nandX is the correct command for restoring the block contents after testing.

For the second question i've found this answer, but in the end it wasn't necessary because no bad blocks were found during the scan.

I've also run a RAM memory test in userspace using the memtester program. It wasn't able to test all the memory, btw no errors were found either.

In the end, i guess/hope the corrupted files i've found were just random write errors due to overheating. Or maybe an ext4 bug in the kernel (uname reports it is v3.4.90)?

Do you think switching to ext2 or ext3 would be safer to prevent these errors?

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.