lkml.org 
[lkml]   [1996]   [Nov]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: PROBLEM in 2.0.24 (fwd)
From
Date
> I had a 24 Gig raid array that had to be fsck'ed.  It couldn't be done on 
> 2.0.24 but I recompiled to 2.0.12 (the only source tree I had sitting
> around) and it worked. I used the e2fsck from e2fsprogs-1.06.

Ok here's the answer, I found it in this same forum:

-Bradley

Path: Q.Net!Q.Net!mail2news-not-for-mail
Newsgroups: linux.dev.kernel
Approved: Ulmo@Q.Net
References: <199610161725.NAA01615@wolverine.hq.cic.net>
From_at-Q-Net: owner-linux-kernel-outgoing@vger.rutgers.edu Wed Oct 16 17:04:37 1996
said_at_Q-Net_Received: from wolverine.hq.cic.net (root@wolverine.hq.cic.net [198.87.19.70])
by Q.Net (8.8.0/8.8.Beta.4) with ESMTP id RAA02585
for <ML-LINUX-KERNEL@q.net>; Wed, 16 Oct 1996 17:04:34 -0400
said_at_Q-Net_Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by wolverine.hq.cic.net (8.8.0/jared) with ESMTP id RAA03651; Wed, 16 Oct 1996 17:00:48 -0400
said_at_Q-Net_Received: by vger.rutgers.edu id <112048-9550>; Wed, 16 Oct 1996 16:52:32 -0400
From: Jared Mauch <jared@wolverine.hq.cic.net>
Message-ID: <199610162051.QAA02596@wolverine.hq.cic.net>
Subject: llseek() broken (Was: mke2fs > 2G?)
In-Reply-To: <199610161725.NAA01615@wolverine.hq.cic.net> from Jared Mauch at "Oct 16, 96 01:25:34 pm"
To: jared@wolverine.hq.cic.net (Jared Mauch)
Date: Wed, 16 Oct 1996 16:51:40 -0400 (EDT)
Cc: tytso@mit.edu, jared@wolverine.hq.cic.net, linux-kernel@vger.rutgers.edu,
linux-libc@vger.rutgers.edu
X-Mailer: ELM [version 2.4ME+ PL27 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk

Ok..

I have rebuilt my ext2fs tools without the libc llseek support,
and with your hacked llseek support.

And now my fancy drives show :-)
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda2 69987 57751 8622 87% /
/dev/sda4 1096024 742464 296931 71% /usr
/dev/md0 513407 2394 484917 0% /news
/dev/md1 20496903 16674 19374384 0% /news/articles

Whee. :-)

I'm running a 5.4.6 libc I think, perhaps .7, so that's
probally the problem, the libc implemtation of llseek is broken. :-)

Hack away.

- jared

Jared Mauch graced my mailbox with this long sought knowledge:
> I'm willing to test.. let me repartition my disks again,
> do some tests as suggested here, and I'll post my results.
>
> - Jared
>
> Theodore Y. Ts'o graced my mailbox with this long sought knowledge:
> > From: Jared Mauch <jared@wolverine.hq.cic.net>
> > Date: Wed, 16 Oct 1996 07:23:00 -0400 (EDT)
> >
> > I'm having problems mke2fsing a filesystem larger than 2 gigs, does
> > anyone know of any limitations to ext2fs? I thought it was 2 terabytes, but
> > I may be wrong..
> >
> > I've personally used e2fsprogs 1.05 to make a 54bib partition.
> >
> > There are some problems making large filesystems that people have
> > reported starting with 1.06, but it appears to be related to whatever
> > libc they are using. I haven't tracked it down any further than that,
> > except that apparently llseek() is failing, so any attempts to access
> > blocks greater than 2GB fails. (It's not just mke2fs, but a freshly
> > compiled e2fsck fails as well, on an already created 4GB partition.)
> >
> > I HAVE NOT BEEN ABLE TO REPRODUCE THIS, but that's probably because I
> > remain very conservative about the libc version that I develop under.
> > (Basically, I have enough problems debugging my own code, that I don't
> > want to worry about debugging libc problems --- and unlike kernel
> > problems, libc problems are *subtle*. For example, Netscape doesn't
> > work with the 5.3 libc that's released with Redhat 4.0. Grumble....)
> > For these reasons, I'm still using libc 5.2.18, from the Redhat 3.0.3
> > release.
> >
> > If someone would like to help me debug this, I'd be very grateful.
> > Basically, what you need to do is to run mke2fs under gdb, and put a
> > breakpoint at the llseek() call in ext2_llseek(), which is located in
> > lib/ext2fs/llseek.c. As you will see by looking at the code, llseek()
> > is only called after you go above 2GB, which is why problems with
> > llseek() won't be noticed for filesystems less than 2GB. When mke2fs
> > hits the break point, single step through the llseek call and see what
> > arguments is being given to it, and what sort of error it is returning.
> >
> > One thing you can try is to add an #undef HAVE_LLSEEK to llseek.c, which
> > will try cause ext2fs_llseek() to use its own home-grown version of
> > llseek(), and avoid using the libc version altogether. If that solves
> > the problem, we'll know where the problem lies.
> >
> > - Ted

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.031 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site