From: Andreas Dilger <adilger@turbolabs.com>
To: Joao Guimaraes da Costa <guima@huhepl.harvard.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: e2fsck compatibility problem with 2.4.17?
Date: Tue, 19 Feb 2002 14:15:38 -0700 [thread overview]
Message-ID: <20020219141538.G25713@lynx.adilger.int> (raw)
In-Reply-To: <3C725D1C.3060001@huhepl.harvard.edu>
In-Reply-To: <3C725D1C.3060001@huhepl.harvard.edu>; from guima@huhepl.harvard.edu on Tue, Feb 19, 2002 at 08:11:40AM -0600
On Feb 19, 2002 08:11 -0600, Joao Guimaraes da Costa wrote:
> I am having a problem that might be due to an incompatibility between
> e2fsck and kernel 2.4.17.
>
> My machine has a redhat kernel 2.4.3-12 and a kernel 2.4.17 I have
> recently built from source.
>
> While doing a routine filesystem check at boot time (running kernel
> 2.4.17), e2fsck found a problem with one of the partitions (I am using
> e2fsck 1.25 from the redhat rawhide rpm e2fsprogs-1.25-2.i386.rpm).
>
> I decided not to fix the problem and checked it with a different kernel
> and version 1.19 of e2fsck. In both cases, the partition was clean.
>
> So, I get:
>
> kernel e2fsck result
> 2.4.17 1.25 problem
> 2.4.3-12 1.25 OK
> 2.4.3-12 1.19 OK
>
> Are there any know incompatibilities between kernel 2.4.17 and e2fsck
> 1.25? Right now, I am not sure if the filesystem is damaged or not!
>
> The error I get is the following:
> 1) e2fsck gets stuck after only checking 2.5% of the partition. It stays
> there for about 5 minutes doing clik-clak noises until starting giving
> errors
> 2) First error is:
> Block 32783 - 32791 (attempt to read block from filesystem resulted in
> short read) while doing inode scan.
> 3) Then in Pass 2:
> resources in /src/linux-2.4.3/drivers/acpi (1894) has deleted/unused
> inode 16435.
Well, this clik-clak noise sounds like a hardware problem. I don't know
why it would only show up under 2.4.17 and not 2.4.3.
Can you try "dd if=/dev/hdX of=/dev/null bs=4k" to see if this completes
under both kernels? Any messages in 'dmesg' that look like IDE errors?
The one thing I also thought of was that kernels 2.4.10+ have the block
devices in page cache, and some people have problems with ulimits when
reading >2GB from the device, but that wouldn't affect block 32783...
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
next prev parent reply other threads:[~2002-02-19 21:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-19 14:11 Joao Guimaraes da Costa
2002-02-19 21:11 ` Mohammad A. Haque
2002-02-19 21:15 ` Andreas Dilger [this message]
2002-02-20 3:13 ` Joao Guimaraes da Costa
2002-02-20 11:31 ` Jan Niehusmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020219141538.G25713@lynx.adilger.int \
--to=adilger@turbolabs.com \
--cc=guima@huhepl.harvard.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®