Filesystem corruption

[caleb]

I have an embedded system running Gentoo Linux in a rather harsh environment. The machine itself may be turned off rather abruptly without a proper shutdown.

In order to help with this, I've made the filesystem span multiple ext3 partitions (one for /usr, one for /, one for /tmp, and one for some other misc. data). All of the partitions are mounted read-only EXCEPT the /tmp one (to allow writing to tmp files).

However, I've noticed that after time I still get some corruptions when running "fsck -f", even if I've cleanly unmounted the filesystems. I would figure that since they're read-only, I shouldn't expect inode problems - especially on clean shutdowns.

So, I guess, this is what I'm asking: will mounting in ro mode help guarantee that I won't get inode issues since it shouldn't be writing to disk. The fact that I *am* getting them...does this suggest a hardware problem (like, I need a more rugged hard disk?)

Caleb

[robdavies]

You seem to have taken very good precautions. Read-only ought to be good protection, you actually don't need to use ext3, as the journaling is superflous read-only (no atime information is written), and could also actually mount /tmp, as tmpfs backed by the vm, configuring the freed partition as swap, so long as there's you don't require persistent data in /tmp across reboots.

There ought not to be problems, running fsck on unmounted filesystems, and fsck -n ought to work well enough even on rw mounted partitions.

Have you a syslog enabled, recording error messages into file in /var/log? That tends to be first point to check when trouble shooting, you ought to see I/O errors from the driver or something.

To test the disk try the badblocks command out, and do a surface scan. Also try memtest86 to eliminate RAM issues, and if you can use UDMA to get checksumming and error detection over the IDE cables.

For soak testing, tools like CPUburn, bonnie++ and other benchmarks ought to be able to show up hardware issues.