I'm been having some hdd problems with my main Fedora 19 system starting during the weekend. The pc has frozen a couple of times after running for some (6-8) hours, but rebooted after. However a couple of other times after a 'normal' shutdown it wouldn't reboot until I ran e2fsck on it (via gparted) from a systemrescuecd.
Here's a truncated report with some example errors (all errors were fixed):
Code:
| calibrate /dev/sda12 00:00:03 ( SUCCESS ) |
| |
path: /dev/sda12 (partition)
start: 1058796018
end: 1140711389
size: 81915372 (39.06 GiB) |
|
| check file system on /dev/sda12 for errors and (if possible) fix them 00:00:12 ( SUCCESS ) |
| |
| e2fsck -f -y -v -C 0 /dev/sda12 00:00:12 ( SUCCESS ) |
| |
Superblock last mount time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
Superblock last write time is in the future.
(by less than a day, probably due to the hardware clock being incorrectly set)
Pass 1: Checking inodes, blocks, and sizes
Interior extent node level 1 of inode 655992:
Logical start 4635 does not match logical start 4685 at next level. Fix? yes
Inode 655992, end of extent exceeds allowed value
(logical block 6472, physical block 6177248, len 16)
Clear? yes |
|
|
[followed by ~couple dozen blocks in the inode with same error, and other errors for this and other inodes listed separately, e.g.:]
Code:
end of extent exceeds allowed value
extent tree (at level 2) could be narrower
i_blocks is 139856, should be 125784
extent tree (at level 1) could be narrower
Deleted inode 1573357 has zero dtime
Inodes that were part of a corrupted orphan linked list found
Failed to optimize extent tree <655992> (655992): Extent not found
Block bitmap differences: -(73225--73235)
Free blocks count wrong
Free inodes count wrong
And summarized thus:
Code:
fc19: ***** FILE SYSTEM WAS MODIFIED *****
313209 inodes used (12.22%, out of 2564096)
1951 non-contiguous files (0.6%)
254 non-contiguous directories (0.1%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 298862/197/8
8409120 blocks used (82.12%, out of 10239421)
0 bad blocks
3 large files
Hopefully "0 bad blocks" in the summary is significant (?) The hdd passed a smartmon quick test with no errors reported. While I had it running from systemrescuecd, I was able to do a backup of recent work to another pc.
The issue apparently arose after I began editing some larger files in GIMP (I recently acquired a new photo scanner), along with running gThumb and Firefox in a memory-constrained (2 GB) environment. This also causes frequent slowdowns and swap thrashing, although so long as I remember to quit out of firefox the slow downs and disk thrashing go away. Apparently fs errors are being introduced by this stress, unless it is just a coincidence.
I have suspected other factors including MB traces damaged during original assembly, and/or (possibly related) ata bus issues. I've had the pc for ~5 or 6-years and it was a cheap-ass msi microATX design that supported my AGP video card
Anyone care to venture a guess as to what is going on with my hdd?
Maybe I just need a new pc :-D I do have a spare new hdd on standby but either way I'd be looking at a full reinstall :-( which I would like to put off :-/ .
“A teen reunited with her birth mother, who then killed her and burned her body, police claim” |