Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

Illegal #-1 blocks

FRED
2009-10-02
2012-11-28
  • FRED
    FRED
    2009-10-02

    I am currently using 1.41.9 e2fsck version on an embedded linux 2.4 system (arch MIPS).
    I would like to know if such messages displayed by e2fsck are normal :
    llegal block #-1 (2291965952) in inode 176.  CLEARED.
    Illegal block #-1 (2324697516) in inode 176.  CLEARED.
    Illegal block #-1 (2303494288) in inode 176.  CLEARED.
    Illegal block #-1 (2326948880) in inode 189.  CLEARED.
    Illegal block #-1 (2291916800) in inode 189.  CLEARED.
    Illegal block #-1 (2282879796) in inode 189.  CLEARED.
    Illegal block #-1 (2303494288) in inode 189.  CLEARED.
    Illegal block #-1 (2324697516) in inode 189.  CLEARED.

    Are #-1 blocks authorized ?
    Does this not sound like a wrap around issue ?

     
  • No, this is definitely not normal, and it does not sound like a wraparound issue (your embedded linux system isn't likely to have such a huge disk as to even come close to using 2^32 blocks).  This is in fact quite a bad symptom, and it indicates filesystem corruption.  You can use debugfs and see which files (or maybe they are directories) happen to be inodes 176 and 189.

     
  • Theodore Ts'o
    Theodore Ts'o
    2009-10-03

    Well, your filesystem is corrupted, but it's not a really horrible thing.  It's likely that the problem was merely caused by a corrupted double indirect block.   Block #-1 simply means a corrupted indirect block.

     
  • FRED
    FRED
    2009-10-05

    Ok, thanks for replying vmo & tytso.

    I am now running a sort of "burning hard disk" test which consists in the following looping sequence:

    1- boot the system <br />
    2- run a forced (-f) e2fsck check<br />
    3- wait for the termination of e2fsck check<br />
    4- run a shell script which creates 10 files with random data. Their filenames are based on the date at bootstart ("date -Iseconds" returned output)<br />
    5- restart the system<br />

    Everything goes well until boot start #28:<br />
    ---------- the STB is reachable 28 ----------<br />
    e2fsck status: 1<br />
    e2fsck 1.41.9 (22-Aug-2009)<br />
    Superblock last mount time (Fri Oct  2 16:52:45 2009,<br />
            now = Thu Jan  1 00:00:05 1970) is in the future.<br />
    Fix? yes<br />

    Superblock last write time (Fri Oct  2 16:53:52 2009,<br />
            now = Thu Jan  1 00:00:05 1970) is in the future.<br />
    Fix? yes<br />

    Pass 1: Checking inodes, blocks, and sizes<br />
    Inode 2042 has illegal block(s).  Clear? yes<br />
    Illegal block #224 **(1145130828)** in inode 2042.  CLEARED.<br />
    Illegal block #225 **(1413563487)** in inode 2042.  CLEARED.<br />
    Illegal block #227 **(1448232275)** in inode 2042.  CLEARED.<br />
    Illegal block #237 **(1330795077)** in inode 2042.  CLEARED.<br />
    Illegal block #238 **(622869074)** in inode 2042.  CLEARED.<br />
    Illegal block #239 **(1952522355)** in inode 2042.  CLEARED.<br />
    Illegal block #304 (1869488229) in inode 2042.  CLEARED.<br />
    Illegal block #305 (1970479220) in inode 2042.  CLEARED.<br />
    Illegal block #306 (1919905904) in inode 2042.  CLEARED.<br />
    Illegal block #307 (174351732) in inode 2042.  CLEARED.<br />
    Illegal block #336 (1920298867) in inode 2042.  CLEARED.<br />
    Too many illegal blocks in inode 2042.<br />
    Clear inode? yes<br />

    Restarting e2fsck from the beginning…<br />
    Pass 1: Checking inodes, blocks, and sizes<br />
    Pass 2: Checking directory structure<br />
    Entry '2009-10-02T16:41:58.6' in / (2) has deleted/unused inode 2042. Clear? yes<br />

    Well, why not…
    Then at bootstart #50, e2fsck has found almost the same blocks sequence:<br />
    ---------- the STB is reachable 50 ----------<br />
    e2fsck status: 1<br />
    e2fsck 1.41.9 (22-Aug-2009)<br />
    Superblock last mount time (Fri Oct  2 17:31:32 2009,<br />
            now = Thu Jan  1 00:00:05 1970) is in the future.<br />
    Fix? yes<br />

    Superblock last write time (Fri Oct  2 17:32:36 2009,<br />
            now = Thu Jan  1 00:00:05 1970) is in the future.<br />
    Fix? yes<br />

    Pass 1: Checking inodes, blocks, and sizes<br />
    Inode 1002 has illegal block(s).  Clear? yes<br />
    Illegal block #224 **(1145130828)** in inode 1002.  CLEARED.<br />
    Illegal block #225 **(1413563487)** in inode 1002.  CLEARED.<br />
    Illegal block #227 **(1448232275)** in inode 1002.  CLEARED.<br />
    Illegal block #237 **(1330795077)** in inode 1002.  CLEARED.<br />
    Illegal block #238 **(622869074)** in inode 1002.  CLEARED.<br />
    Illegal block #239 **(1952522355)** in inode 1002.  CLEARED.<br />
    Illegal block #340 (1735287144) in inode 1002.  CLEARED.<br />
    Illegal block #341 (622879845) in inode 1002.  CLEARED.<br />
    Illegal block #342 (1965367413) in inode 1002.  CLEARED.<br />
    Illegal block #352 (1868983881) in inode 1002.  CLEARED.<br />
    Illegal block #353 (622869024) in inode 1002.  CLEARED.<br />
    Too many illegal blocks in inode 1002.<br />
    Clear inode? yes<br />

    Restarting e2fsck from the beginning…<br />
    Pass 1: Checking inodes, blocks, and sizes<br />
    Pass 2: Checking directory structure<br />
    Entry '2009-10-02T16:32:58.8' in / (2) has deleted/unused inode 1002.  Clear? yes<br />

    So, I do not know how to interpret such results…
    All I can say is:<br />
    1- errors are always found during the pass 1 step<br />
    2- older inodes are cleared by e2fsck. For instance, here the inode #2042 was created at bootstart #20 and deleted at bootstart #28<br />
    3- each time e2fsck has found an error the cause is 'block >= fs->super->s\_blocks\_count' according to the 'describe\_illegal\_block' function. The filesystem check here has only 19500901 blocks. The illegal blocks found by e2fsck were really too big !!!

    Any comments ? I do not know where is the problem…

     
  • FRED
    FRED
    2009-10-05

    Sorry for my last message… The preview was good…

     
  • Theodore Ts'o
    Theodore Ts'o
    2009-10-05

    Well, if you look at those numbers, and convert them into ASCII you get: " LOAD_DAT_ERV_ERROR: %s".    So it's ascii text which is getting written into an indirect block, first of inode #2042 and then of inode #1002.  do you have multiple partitions on that device (and if so, have you checked to make sure the partition table isn't corrupt), or some other OS that might be wrtiting blocks to the wrong location on disk? 

     
  • FRED
    FRED
    2009-10-06

    Thanks a lot Tytso !
    We have a swap partition.
    After analysing of the e2fsck logs, and thanks to your remark, we found other strings such as "Not tainted". This string is present only in our linux kernel code source!!!

    Seems we have to look for bugs in our source code. We disabled use of mmap() in e2fsck but without any success.

     
  • Theodore Ts'o
    Theodore Ts'o
    2009-10-06

    Well, blocks are clearly getting written to the wrong location on disk, so that tends to indicate either some kind of hardware problem (or more likely in your case) some kind of kernel bug that is causing blocks to be written to the wrong location.   It's certainly not normal and I haven't seen anyone else reporting problems like this with ext2/ext3.

     
  • FRED
    FRED
    2009-10-06

    Tytso >>
    Yes we found a bug in our linux IDE disk driver. This is not a e2fsck issue.
    Sorry for disturbing. Thanks a lot for your great help.

    Regards.