2

On an embedded system I have, using a 44 pin transcend industrial flash, after a while I will notice that I cannot read any files or write to the disk. I am using the 3.2.0.* BPO i686 SMP PAE kernel. This is sometimes accompanied by a freeze on the backport's kernel, but it always caused a complete system freeze on the default Debian 6 kernel. When I try to reboot at this point, it always freezes, if I cycle power (something that is normally fine since this is a read-only root system) I usually get a stuck boot on fsck complaining that one of the writable partitions was not cleanly unmounted. fsck /dev/... -y always fixes it.

When I noticed this, I altered our main application to only read from the ide at startup and to only write to the configuration files when the client calls a WriteConfigurationToDisk function. This drastically improved matters, however, after a while the same thing begins to happen. This does not seem to happen universally, just on about 10% of the product.

This is a read-only root system. Each partition is a journaled ext3 file system. Also, only the operating system is writing anything to the disk--and most of that is at boot up. Any ideas on what I should check?

Update I have been doing some more research and it seems that ext3 maybe murdering my flash drive, hence the frozen read/writes are a result of a bad flash. Should I maybe switch to JFSS2?

Jonathan Henson
  • 889
  • 2
  • 10
  • 16

1 Answers1

3

On SSDs you could try using the ext4 filesystem, then mount it using the discard option. In fstab:

UUID=XXXXXXXXXXXX       /            ext4     discard         0       1

Add whatever other options you want, such as noatime or errors=remount-ro.

The discard option potentially enables TRIM in the SSD which may increases its lifetime, https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Ext4_code_implements_discard.2FTRIM

However this will only work if other (underlying) systems support it as well.

I am not sure if your flash disk supports TRIM, since it's not part of the chips itself but part of the logic of the drive that contains the chips. I'd need to know exactly what kind of device it is.

But just changing the filesystem itself may alleviate things, I prefer xfs. The ext3 filesystem is good enough for many purposes, but has more of those recovery issues (requiring fsck -y) than others such as xfs which I have never found to bail out on me.

Setting this in /etc/default/rcS enables automatic repair of the (ext3) filesystem at boot up, no need to hit "y":

FSCKFIX=yes

Update: I checked the specs of that device and it appears it does not support TRIM, it's quite a nice little device though. You're right about the journaling and if TRIM is not supported you may have better reliability using the ext2 filesystem, or another non journaling filesystem.

aseq
  • 4,550
  • 1
  • 22
  • 46
  • 1
    Thank you for answering! It is a emphase 44 pin 8000 series 4 gb industrial flash ide. The documentation has all of this information in it, though admittedly I don't know how to read most of it, since I am a software engineer, not a systems engineer. I tried ext4 with journaling. From what I gathered, the journaling on the ext file systems writes unevenly and way too frequently. So, recently I have been experimenting with mtd. Am I wrong about this assumption? – Jonathan Henson Aug 23 '12 at 17:57
  • See my updated answer. – aseq Aug 23 '12 at 19:02
  • If I don't use a journaling system, how will I recover data after a power loss? – Jonathan Henson Sep 12 '12 at 14:20