What exactly does the automated ext3 root file system check?
Recently we encountered a problem (bad blocks) with an ext3 formatted compact flash card running an embedded Linux system. On startup, the root file system check was started, but it seemed to hang since it took much longer than usual. Later I plugged the card into another PC and I detected bad blocks. I wonder now if the initial root file system check would have found an repaired the blocks too, if I had waited long enough. To find it out I checked the tune2fs and e2fsck man pages but could not find the answers to my questions:
Can I influence the checks/repairs that are performed with these automated root file system checks? If yes, how can I configure it?
If it is not possible to configure: What exactly is checked or repaired, what are the default settings, what flags are used for the automated check?
if the initial root file system check would have found an repaired the blocks
The OS will only trigger an automatic, full fsck in ext3 if the filesystem does not have journalling enabled and the system crashed or the remount limit is reached. It would have detected the bad blocks if you had attempted to write or read them - but this would not have triggered an automatic fsck - it would either remount the disk read-only or throw a kernel panic depending on how it has been configured.
Assuming that it's set up for journalling, then the tests done at mount only check what journal operations may have to be rolled forward.
I checked the tune2fs
Did you see what the -i, -C and -c flags do? (note that these only trigger an fsck at some future reboot - it is not possible to schedule a root fsck on a running system).
CF technology is getting rather long in the tooth and relatively expensive compared to other formats - begging the question how old is this card, and is it worth trying to save it. While it's quite possible to run an operating system of such devices, they're not really intended for this purpose - SATA connected nand flash drives are becoming commonplace but the reason they cost so much more than, say SD cards, is that include a lot of smarts for managing the storage and dealing with bad blocks.
Unfortunately there's no filesystem able to manage basic, write-limited storage devices connected via IDE/SCSI/USB (JFFS2 exploits direct acces to the underlying storage - i.e. devices plugged into the PCIe bus).
It's certainly a very ad idea to expect the CF device to behave like a normal disk - take a look at puppy - it does some very clever stuff with overlays to reduce the amount of writes to the disk, although it's possible to do a lot of tuning on all filesystems to reduce the frequency of writes - have a look at the recommendations for tuning Linux on Laptops to reduce I/O.