Chris's questions

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:

1. Can I influence the checks/repairs that are performed with these automated root file system checks? If yes, how can I configure it?

2. 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?

I use a script to partition and format CF cards (connected with a USB card writer) in an automated way. After the main process I check the card again with fsck. To check bad blocks I also tried the '-c' switch, but I always get a return value != 0 and the message "FILE SYSTEM WAS MODIFIED" (see below). I get the same result when checking the very same drive several times...

Does anyone know why a) the file system is modified at all and b) why this seems to happen every time I check and not only in case of an error (like bad blocks)?

Here's the output:

linux-box# fsck.ext3 -c /dev/sdx1
e2fsck 1.40.2 (12-Jul-2007)
Checking for bad blocks (read-only test): done
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

Volume (/dev/sdx1): ***** FILE SYSTEM WAS MODIFIED *****
Volume (/dev/sdx1): 5132/245760 files (1.2% non-contiguous), 178910/1959896 blocks

I plug a completely clean CF-card into my USB card-writer. Then I dd a mbr block of 512 bytes size to the device, which contains the partition table and the definition of one partition.

Problem: While "fdisk -l /dev/sdx" correctly displays the partition, it happens that there is no device like "/dev/sdx1" after these operations (as it was not present before). Unplugging and plugging the card-writer solves the problem and makes the device(s) appear. Since I use this procedure in a script, manually unplugging and re-plugging is no option whatsoever.

Is there a way to "refresh" the devices or to "unplug and re-plug" the drive by script such that /dev/sdx1 appears?

Thanks for any help,

Chris

For an embedded system I create a filesystem with mkfs.ext3 on a desktop computer. Currently I'm evaluating newer distros for the desktop while the embedded stays the same. When checking the filsystem created with the new distro on the embedded device with fsck.ext3 I get the error "Filesystem has unsupported feature(s)" or "fsck failed (status 0x8)".

How can I find out which features are causing the problem as the error message is not very helpful? Is there a chance to create a filesystem identically to the ones created earlier by using the right switches of mkfs or does it add features I can't turn off?

Thanks, Chris