| View previous topic :: View next topic |
| Author |
Message |
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
 Posted: Sun Mar 20, 2011 8:01 am Post subject: EXT4-fs (sda3): error count: 1 |
 |
|
Hi guys
Does anyone know what this means?
| Code: | [ 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  |
|
| Back to top |
|
 |
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Sun Mar 20, 2011 10:36 am Post subject: |
|
|
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 | Code: | | 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 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:
4. Restore the file if possible (e.g., if it was part of a package, re-emerge the package).
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
| Posted: Sun Mar 20, 2011 10:57 am Post subject: |
|
|
How very interesting.....
| Code: | ./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:
| Code: | [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!  |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Mon Mar 21, 2011 12:29 am Post subject: |
|
|
Glad it worked.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
| Posted: Mon Mar 21, 2011 7:52 am Post subject: |
|
|
It looks like I spoke too soon 
| Code: | [ 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? |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Mon Mar 21, 2011 12:59 pm Post subject: |
|
|
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.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
| Posted: Mon Mar 21, 2011 2:46 pm Post subject: |
|
|
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?: | Code: | 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) |
|
| Back to top |
|
|
Aquous
l33t
Joined: 08 Jan 2011
Posts: 700
|
| Posted: Mon Mar 21, 2011 6:06 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Mon Mar 21, 2011 10:01 pm Post subject: |
|
|
| 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?: | Code: | 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) |
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. 
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Mon Mar 21, 2011 10:14 pm Post subject: |
|
|
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
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
Bones McCracker
Veteran
Joined: 14 Mar 2006
Posts: 1611
Location: U.S.A.
|
| Posted: Mon Mar 21, 2011 10:27 pm Post subject: |
|
|
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.
_________________
| patrix_neo wrote: | The human thought: I cannot win.
The ratbrain in me : I can only go forward and that's it. |
|
|
| Back to top |
|
|
|
Kernel & Hardware
