[opensuse] ext3 about to die? I hope not...
I have an openSUSE 10.3 system that seems to be working fine, except I get the following messages repeated continuously in /var/log/messages: kernel: attempt to access beyond end of device kernel: sda1: rw=32, want=135266312, limit=28933002 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 4096 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 8192 kernel: attempt to access beyond end of device kernel: sda1: rw=32, want=15629549576, limit=28933002 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 12288 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 16384 kernel: attempt to access beyond end of device kernel: sda1: rw=32, want=672137224, limit=28933002 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 20480 kernel: EXT3-fs error (device sda1): ext3_readdir: directory #605117 contains a hole at offset 24576 This continues with the offset continuing to increase by 4096. The file system is in use. It seems to be working ok. Just these messages. The disk looks like this (as expected): Disk /dev/sda: 80.0 GB, 80026361856 bytes 255 heads, 63 sectors/track, 9729 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Disk identifier: 0x000d109e Device Boot Start End Blocks Id System /dev/sda1 * 1 1801 14466501 83 Linux /dev/sda2 1802 3601 14458500 f W95 Ext'd (LBA) /dev/sda3 3602 9729 49223160 83 Linux /dev/sda5 1802 1901 803218+ 82 Linux swap / Solaris /dev/sda6 1902 3601 13655218+ 83 Linux The mount info looks like this (as expected): Filesystem Size Used Avail Use% Mounted on /dev/sda1 14G 12G 1.4G 90% / udev 252M 96K 252M 1% /dev /dev/sda3 47G 34G 11G 77% /home Perhaps I have a corrupt directory somewhere that is referring to some places past the end of the disk. How could I find out which directory is #605117? Or am I looking at this wrong? A bit of Googling suggested (among lots of strange things) that fdisk may originally have reported the partition size wrong, and now the file system is trying to access a part that never really existed. Seems odd. How would I see f this is the case? The info I supplied above implies that both fdisk and mount think the partition is 14 GB. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Bad form to follow up. But there had been a development... The file system can no longer be mounted. fsck claims that the superblock is bad. Yee hah. When openSUSE 10.3 is installed, would a ext3 root file system have an alternate superblock? fsck won't do anything unless I specify an alternate superblock. It suggests the command 'e2fsck -b 8193'. But is that just a generic example, or is that probably a real alternate superblock? Alternately, has anyone tried the -S option to mkfs.ext2? Any things I should consider? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Hi! Am Freitag, 29. August 2008 09:14 schrieb Roger Oberholtzer:
anything unless I specify an alternate superblock. It suggests the command 'e2fsck -b 8193'. But is that just a generic example, or is that probably a real alternate superblock?
Shouldn't hurt to try. It will contain if that's not a valid superblock. Are you on a raid? I had a case were a cable was loose and the raid wouldn't start up. However that only flashed by during startup and the first thing I really noticed was the system complaining about being unable to mount. And e2fsck obviously didn't work in that case ;) So make sure your drive is actually up. Took me a while to figure that out. -- Matthias Bach www.marix.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2008-08-29 at 10:24 +0200, Matthias Bach wrote:
Hi!
Am Freitag, 29. August 2008 09:14 schrieb Roger Oberholtzer:
anything unless I specify an alternate superblock. It suggests the command 'e2fsck -b 8193'. But is that just a generic example, or is that probably a real alternate superblock?
Shouldn't hurt to try. It will contain if that's not a valid superblock.
I was not sure about that. But as you imply, there must be some signature in the superblock that makes it less likely to use random data as a superblock.
Are you on a raid? I had a case were a cable was loose and the raid wouldn't start up. However that only flashed by during startup and the first thing I really noticed was the system complaining about being unable to mount. And e2fsck obviously didn't work in that case ;) So make sure your drive is actually up. Took me a while to figure that out.
The disk is a single disk. I can access it just fine in read-only when the system forces me into maintenance mode during boot. It is just that the system will not fsck it, and thus will not mount it rw when the system boots. Of course, it is the root disk. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Summary: My original question was about finding a bad inode, which was causing the kernel to list a zillion messages to /var/log/messages. Nothing came of that, so I decided to reboot, and then found myself in the position of the boot process not wanting to mount this partition. It suggested that I run e2fsck on the file system. When I did this, e2fsck claimed that the superblock was bad, and suggested another e2fsck command, which also claimed that the superblock was bad. Things looked bleak. Solution: Do not run e2fsck, as suggested in the text when the boot puts you in maintenance mode (root login). Instead, run fsck. When I did this, fsck did not complain about the superblock. Instead, it ran the check. And, happily, it detected the inode that was the original cause of the problem and repaired it. The file system is now back on line. Does the e2fsck program require additional parameters if run direct? Things like block size and whatnot? If so, it may be bad to suggest using it in the boot help message in this context. Or, at least tell which options will be REQUIRED for e2fsck to function. Better yet, suggest running fsck instead, and let fsck figure out the options. That is, after all, fsck's job. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Roger Oberholtzer wrote:
Summary:
My original question was about finding a bad inode, which was causing the kernel to list a zillion messages to /var/log/messages. Nothing came of that, so I decided to reboot, and then found myself in the position of the boot process not wanting to mount this partition. It suggested that I run e2fsck on the file system. When I did this, e2fsck claimed that the superblock was bad, and suggested another e2fsck command, which also claimed that the superblock was bad. Things looked bleak.
Solution:
Do not run e2fsck, as suggested in the text when the boot puts you in maintenance mode (root login). Instead, run fsck. When I did this, fsck did not complain about the superblock. Instead, it ran the check. And, happily, it detected the inode that was the original cause of the problem and repaired it. The file system is now back on line.
Does the e2fsck program require additional parameters if run direct? Things like block size and whatnot? If so, it may be bad to suggest using it in the boot help message in this context. Or, at least tell which options will be REQUIRED for e2fsck to function. Better yet, suggest running fsck instead, and let fsck figure out the options. That is, after all, fsck's job.
There is fsck.ext2 and fsck.ext3, fsck just picks the correct one to use. Regards Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Dave Plater wrote:
There is fsck.ext2 and fsck.ext3, fsck just picks the correct one to use.
On my 10.3 system /sbin/e2fsck, /sbin/fsck.ext2 and /sbin/fsck.ext3 are all hardlinks to the same file. Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2008-08-29 at 11:35 +0100, Dave Howorth wrote:
Dave Plater wrote:
There is fsck.ext2 and fsck.ext3, fsck just picks the correct one to use.
On my 10.3 system /sbin/e2fsck, /sbin/fsck.ext2 and /sbin/fsck.ext3 are all hardlinks to the same file.
Interesting. Same here. But fsck is, of course different. No matter which binary fsck eventually runs, it must be supplying options not suggested in the boot message. -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, 2008-08-29 at 12:25 +0200, Dave Plater wrote:
There is fsck.ext2 and fsck.ext3, fsck just picks the correct one to use.
OK. And then fsck.ext2 sets up the required options to e2fsck for the actual checking. I am not a Linux/Unix newbie (> 20 years using Unix and then Linux). But, luckily, I seldom have to run fsck on a file system, let alone the actual file system-specific checkers themselves that fsck will in turn run. Kudos to Linux file system developers for making me almost fsck illiterate :) Given that most people never run the file system-specific checkers and thus have little experience with them, I think it is unnecessarily confusing to suggest, in an incomplete manner, that users do this when the boot fails. I guess that an alternative was for me to run the 10.3 recovery from the 10.3 install DVD. Would that have run fsck more completely, not stopping like the boot does and making ne run fsck by hand? If so, it could be a great idea to suggest this in the boot message as well. Of course, I heard rumors that the recovery in the 10.3 GM DVD was broken. Was that just a rumor? -- Roger Oberholtzer OPQ Systems / Ramböll RST Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Office: Int +46 8-615 60 20 Mobile: Int +46 70-815 1696 And remember: It is RSofT and there is always something under construction. It is like talking about large city with all constructions finished. Not impossible, but very unlikely. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (4)
-
Dave Howorth -
Dave Plater -
Matthias Bach -
Roger Oberholtzer