fsck of EXT3 reporting "short reads"
Hello,
I recently found one of my EXT3 filesystems somehow got hosed. This is on a Slackware 10.1 box with kernel 2.4.29. The filesystem can be mounted, but then doing an 'ls' of the directory seems to hang. While unmounted, if I run e2fsck /dev/sda1 I get a whole bunch of errors: Error reading block 622595 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes Error reading block 622596 (Attempt to read block from filesystem resulted in short read) while doing inode scan. Ignore error? yes Force rewrite? yes And it just goes on for a long time; so long that it would probably take days to finish. It is interesting that these errors occur in groups of 4 consecutive blocks, spaced 32,768 blocks apart (which also happens to be the block group size). Here is a dump of the superblock information: root@host:/home/dogberry# dumpe2fs -h /dev/sda1 dumpe2fs 1.35 (28-Feb-2004) Filesystem volume name: <none> Last mounted on: <not available> Filesystem UUID: 6d92ada6-e697-43d2-9129-fc7516c700f2 Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal filetype sparse_super large_file Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 194560 Block count: 49785427 Reserved block count: 0 Free blocks: 502737 Free inodes: 163515 First block: 0 Block size: 4096 Fragment size: 4096 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 128 Inode blocks per group: 4 Filesystem created: Sat Jan 15 22:10:10 2005 Last mount time: Sat Apr 28 15:32:15 2007 Last write time: Sat Apr 28 15:36:33 2007 Mount count: 7 Maximum mount count: 30 Last checked: Sat Nov 4 08:37:40 2006 Check interval: 15552000 (6 months) Next check after: Thu May 3 09:37:40 2007 Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 128 Journal inode: 8 Default directory hash: tea Directory Hash Seed: fd72b0fd-4171-4254-86bd-cd3964223ab1 Journal backup: inode blocks Another thing that might be relevant is that this filesystem just recently began to fill up, which I stupidly ignored. I wouldn't think it would cause something like this to happen. Maybe there are bad blocks? The fact that the blocks reported by fsck are so evenly spaced makes me think that there is something else wrong. Suggestions? Thanks in advance!!! Dogberry |
While I cannot suggest what you SHOULD do, or exactly why you are getting the short reads, I CAN tell you a little tiny bit about my own machine, in the hope that **maybe** you might be able to come up with some ideas. I have on occasion had the short reads as well. Things to note are such stuff as memory timings/bad memory on the PC, DMA being enabled, incorrect HDPARM settings, or bad/rapid shutdowns:
I use an Intel Pentium 4 1.8 Ghz. It's overclocked by about 400 Mhz so it runs at 2.21 Ghz. I have enabled 32 bit IO transfers through the BIOS, as well as with HDPARM in my boot scripts. I have DMA enabled in the BIOS for both IDE busses, as well as UDMA enabled using HDPARM for 3 of the 4 drives I have (the 4th one just isn't capable). I have enabled hdparm -c3 (32 bit w/sync mode) on my main harddrive, a 320 GB Seagate. So all this works perfectly well 99% of the time. Recently I started playing around a little bit with some more HDPARM arguments on my main hard disk and the 2nd hard disk (the other 2 devices are optical) including -K and -k which keep drive settings over reset. One of the K options caused me to have that same crap about short reads on EVERY reboot. e2fsck wouldn't finish by itself I had to run it manually, sometimes twice with -v -y argumants (verbose && yes-to-all-questions). It did take longer than usual too, but ALWAYS recovered the filesystem no problem. Also, the second hard disk seemed to get 'hung' once in a while, where the light would be on but no one was home :p.. No drive activity, and it wouldn't respond when shutting down. I removed the -K and -k options from the second hard drive, and removed ONE of the K options from the main Hard drive, and that instantly solved the short reads. Now it reboots perfectly, and never needs fsck on reboot. On other separate occasions when I was getting short-reads, as well as 'seek-not-ready' and 'no DMA' type errors, and DMA was turning off by itself all the time, it was because I had the PCI/AGP frequency settings in the BIOS slightly out of whack, and something that also contributed to the IDE errors all the time was having the BIOS Memory Clock Speed set to AUTO. AUTO was bad news, and I was ALWAYS getting screwed up hard disk; it would almost never reboot properly. I set the Memory Clock Speed to the next lower numerical setting, and loosened the memory timings by one clock cycle, and presto. Fixed. As I write this, The whole machine is running like a swiss watch :) and haven't had a fscking problem since. :p The moral of the story -- If you have either a ) high performance settings b ) bad memory hardware c ) poorly tuned BIOS/Clock/Timing settings d ) Incorrectly configured IDE device settings e ) Old, crappy or damaged IDE cables in your machine .. and likely other stuff, they may be contributing to the problem. Again, not sure any of this will pertain to *your* particular IDE issue, but hopefully someone will find the info useful.. |
Check with /sbin/badblocks?
You should save all important data before doing anything... |
All times are GMT -5. The time now is 04:28 PM. |