# EXT4-fs (sda3): error count: 1

## Aquous

Hi guys

Does anyone know what this means?

```
[  305.274910] EXT4-fs (sda3): error count: 1

[  305.274916] EXT4-fs (sda3): initial error at 1300215660: htree_dirblock_to_tree:586: inode 5382874: block 21504551

[  305.274924] EXT4-fs (sda3): last error at 1300215660: htree_dirblock_to_tree:586: inode 5382874: block 21504551
```

fsck reports no problems and the system runs fine, but this shows up in dmesg after every first emerge action performed since boot (though that may be a coincidence).

The disk is brand new (~4 months old), but I have had some issues with it in the past (which my IT guy assures me were all my own fault and not a hardware problem).

Thanks for any insights  :Smile: 

----------

## Bones McCracker

I would assume it is some kind of filesystem corruption.

Disclaimer: this may be wrong, or even stupid, but it's probably the next thing I'd do.

1.  Figure out what file it is.  You can use 'find -inum' to get the filename of whatever is using inode 5382874

First, cd to the filesystem root of the ext4 filesystem in question (i.e., the filesystem's mount point)

Then, do

```
find -xdev -inum 5382874
```

That should tell you the filename of whatever is using the offending inode.

2.  Figure out what the file is.  You can check to see what package (if any) owns it by doing:

```
qfile <filename>
```

(qfile is part of portage-utils)

2.  Figure out how to get rid of the corrupt inode.  Probably just delete the file.

3.  Check the filesystem for bad blocks:

```
e2fsck -c <device>
```

4.  Restore the file if possible (e.g., if it was part of a package, re-emerge the package).

----------

## Aquous

How very interesting.....

```
./usr/lib64/opengl/global/include

find: './usr/lib64/python2.6/site-packages/pygame/tests/__main__.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/run_tests__tests/all_ok/fake_5_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/run_tests__tests/all_ok/__init__.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/run_tests__tests/all_ok/fake_6_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/run_tests__tests/all_ok/fake_2_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/cursors_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/mixer_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/blit_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/mixer_music_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/display_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/__init__.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/base_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/midi_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/font_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/fastevent_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/joystick_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/mouse_test.pyo': I/O error

find: './usr/lib64/python2.6/site-packages/pygame/tests/image_test.pyo': I/O error
```

It's very interesting because quite a while ago my system was shutdown uncleanly (through a fault of my own) and after that fsck reported two lost files; one of which had the very contents of an OpenGL header file.

There's also this:

```
[10793.648827] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509518

[10793.657641] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509394: comm find: deleted inode referenced: 5509551

[10793.657911] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509394: comm find: deleted inode referenced: 5509547

[10793.658087] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509394: comm find: deleted inode referenced: 5509552

[10793.658272] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509394: comm find: deleted inode referenced: 5509548

[10793.676805] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509525

[10793.677038] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509539

[10793.677675] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509520

[10793.678014] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509538

[10793.678320] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509526

[10793.678553] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509517

[10793.678815] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509519

[10793.679030] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509537

[10793.679206] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509530

[10793.679368] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509529

[10793.679518] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509534

[10793.679754] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509540

[10793.679981] EXT4-fs error (device sda3): ext4_lookup:1043: inode #5509391: comm find: deleted inode referenced: 5509533
```

So basically my filesystem is slightly messed up in a way fsck can't detect.

I did rm -rf /usr/lib64/python2.6/site-packages/pygame/tests /usr/lib64/opengl/global/include and am now re-emerging pygame and eselect-opengl.

edit: rm -rf /usr/lib64/python2.6/site-packages/pygame failed with I/O error because the inode appears to be gone already, yet is still listed in the directory listing... I think... I wouldn't know how to proceed. Re-emerge of pygame showed the same errors during the 'unmerging already installed instance' part.

Should I reformat/reinstall (it's not that big of a hassle to me) just to be safe?

Edit2: scratch the above, e2fsck found & repaired the deleted inodes and pygame managed to re-emerge cleanly. So my problems appear to have been solved.

Thanks BoneKracker!   :Very Happy:   :Very Happy: 

----------

## Bones McCracker

Glad it worked.   :Smile: 

----------

## Aquous

It looks like I spoke too soon  :Sad: 

```
[  305.275140] EXT4-fs (sda3): error count: 213

[  305.275146] EXT4-fs (sda3): initial error at 1300215660: htree_dirblock_to_tree:586: inode 5382874: block 21504551

[  305.275153] EXT4-fs (sda3): last error at 1300618850: ext4_lookup:1043: inode 5509391
```

Inode 5382874 is nowhere to be found, inode 5509391 belongs to /usr/lib64/python2.6/site-packages/pygame/tests

I get no I/O errors this time and e2fsck finds nothing:

  993867 inodes used (15.17%)

    8220 non-contiguous files (0.8%)

     500 non-contiguous directories (0.1%)

         aantal inodes met ind/dind/tind-blokken: 0/0/0

         Extents-dieptehistogram: 981481/454

 7594318 blocks used (28.97%)

       0 bad blocks

       1 large file

  938809 regular files

   42998 directories

    1049 character device files

    4089 block device files

      34 fifos

    3129 links

    6876 symbolic links (6747 fast symbolic links)

       3 sockets

--------

  996987 files

(got the log by mounting a ramdisk, init 1, e2fsck -vfp | tee /mnt(ramdisk is here)/log, init 3, copy over log))

Time to reinstall?

----------

## Bones McCracker

That sucks.  If it were me, yeah, that's probably what I'd do.

Also before installing, I would do some low-level disk maintenance.

----------

## Aquous

Yep, it's a shame. I'm building a stage4 from the (awesome) Gentoo live dvd as we speak though  :Smile: 

What do you mean by low-level disk maintenance? Just this?:

```
badblocks -w -o ~/badblocks /dev/sda3

mkfs.ext4 -l ~/badblocks -j -L Gentoo -O extent /dev/sda3
```

Or do you mean to reinitialize the partition table? (as my IT guy told me to when I experienced random "disk errors" after I had switched from 32 bit Windows 7 to 64 bit)

Note: after my IT guy told me to wipe the partition table I did a low level format using the official tool from my drive manufacturer, and it reported no errors (which backed up my IT guy's story about my drive being "confused" by the switch from 32 bit to 64 bit). So I should not have any bad blocks. Right? (I know you're (probably) not a HDD guru, but you seem to know your stuff, so I figured I might as well ask)

----------

## Aquous

Well, it looks like my system will live to see another day.

I managed to successfully do the stage4 backup & restore and all seems well (though I did have some random consolekit+dbus failure, which I fixed by re-emerging both those packages).

Thanks, BoneKracker, for your guidance, you've taught me a lot over these two days   :Smile: 

----------

## Bones McCracker

 *Aquous wrote:*   

> Yep, it's a shame. I'm building a stage4 from the (awesome) Gentoo live dvd as we speak though 
> 
> What do you mean by low-level disk maintenance? Just this?:
> 
> ```
> ...

 

Yes, I meant checking the disk with tools from the manufacturer, reinitializing the partition table, repartitioning, creating new filesystems, and so on.  If the tools from the drive manufacturer are saying the drive is in pristine condition, I would not worry about bad blocks.

You may never know what caused it.  Maybe it was a solar flare or a manifestation of the coming Galactic Alignment of 2012.  You might want to make a point of backing up important data if you were not already doing so.   :Razz: 

----------

## The Doctor

When creating a new file system, I like to use the mkfs.ext4 -c -c option. This takes a while, but at least the disk gets checked for bad sectors.

THIS WILL OVERWRITE ALL DATA WITH TEST PATTERS, SO USE WITH APPROPRIATE CARE

----------

## Bones McCracker

Normally I would say, "Don't listen to penguin swordmaster", but there's probably no harm in doing this, even though it will take a long time.   :Razz: 

----------

