3

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
Ben Pilbrow
  • 12,041
  • 5
  • 36
  • 57
Chris
  • 225
  • 1
  • 3
  • 8

3 Answers3

3

Quoth the manpage:

-c
This option causes e2fsck to run the badblocks(8) program to find any blocks which are bad on the filesystem, and then marks them as bad by adding them to the bad block inode. If this option is specified twice, then the bad block scan will be done using a non-destructive read-write test.

Therefore the -c option writes to the filesystem, which fsck interprets as "correcting errors", hence the return code of 1 ("File system errors corrected")

...so, you ask, why does it return 1 when you specify -n, which should open the filesystem read-only and make no changes?
Well, further reading of the manpage reveals that answer too:

-n Open the filesystem read-only, and assume an answer of `no' to all questions. Allows e2fsck to be used non-interactively. (Note: if the -c, -l, or -L options are specified in addition to the -n option, then the filesystem will be opened read-write, to permit the bad-blocks list to be updated. However, no other changes will be made to the filesystem.)

(in other words: The -n is a lie!)

This answer brought to you entirely by the manpage for fsck.ext3.

voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • 1
    One thing I failed to point out is that the use of `-c` or `badblocks` is pretty much a relic: Modern hard drives (the last generation of IDE, All SCSI, All SATA) internally remap bad blocks from a pool reserved for that purpose. If your system is at the point where the OS can see bad blocks your disk is not dying - it's *dead*, and you're smelling it decompose. Accordingly you can probably dispense with passing `-c` entirely... – voretaq7 Jul 23 '12 at 20:34
  • First of all, thanks for the response. My question a) is answered, it originated in a misunderstanding of what is exactly meant with the file system and yes, I am capable of reading. Still, I cannot see the answer to b). Why is the bad block inode modified if there were no bad blocks? _so, you ask, why does it return 1 when you specify -n_ No. – Chris Jul 24 '12 at 12:56
  • About your comment: Yes I know, but as I mentioned in my question, I'm talking about CF cards. Unfortunately it is not possible to change hardware as easy as in your personal computer when talking about embedded systems with several thousand installed pieces. – Chris Jul 24 '12 at 13:00
  • @Chris The bad blocks list is updated any time badblocks (or fsck -c) runs. That's a stupid design decision, but it's the one they made. Everything I said about hard drives holds true for solid state media: By the time you see bad sectors the hardware is shot, further failures become more likely, and you should be looking to replace it before it fails and takes your data with it. Solid-state media is less likely to fail catastrophically, but also less likely for a sector to be recoverable when its cell dies... – voretaq7 Jul 24 '12 at 15:16
  • "The bad blocks list is updated any time badblocks (or fsck -c) runs. That's a stupid design decision." That was what I wanted to be confirmed. Thanks. – Chris Oct 30 '12 at 11:54
  • @voretaq7: Turning off badblock remapping and letting the OS handle it is a good idea on RAID. – joshudson Jun 28 '16 at 22:23
0

Did you try the -v switch to fsck to get more information? Also you can try to run badblocks alone and examine its output.

Juraj
  • 257
  • 3
  • 9
  • Thanks for the -v hint, but this does not help a lot. badblocks runs fine with return value 0. – Chris May 17 '10 at 12:56
0

Most likely there was a write to the filesystem "label" area. What about the date/time last fsck'd and the number of times since the last mount count fields in the filesystem label?

If you look at the tune2fs parameters, this would type of write would support the -c and -i parameters for the automatic full fsck support for an ext3 filesystem.

mdpc
  • 11,856
  • 28
  • 53
  • 67
  • This makes no sense to me, running 'fsck -n /dev/sdx1' works fine with return value 0, as well as 'badblocks /dev/sdx1'. But the combination of both, 'fsck -cn /dev/sdx1', alters the file system and ends with return value 1 each time? I'm confused. – Chris May 17 '10 at 12:59