From: "Theodore Ts'o" <tytso@mit.edu>
To: Simon Kirby <sim@netnation.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
Linux-raid maillist <linux-raid@vger.kernel.org>,
Jens Axboe <axboe@suse.de>, Neil Brown <neilb@cse.unsw.edu.au>,
"Kevin P. Fleming" <kpfleming@backtobasicsmgmt.com>,
LKML <linux-kernel@vger.kernel.org>,
linux-lvm@sistina.com
Subject: Re: Reproducable OOPS with MD RAID-5 on 2.6.0-test11
Date: Fri, 5 Dec 2003 01:55:22 -0500 [thread overview]
Message-ID: <20031205065522.GA28825@thunk.org> (raw)
In-Reply-To: <20031204043106.GA19017@netnation.com>
On Wed, Dec 03, 2003 at 08:31:06PM -0800, Simon Kirby wrote:
>
> Without the patches, the box gets as far as assembling the array and
> activating it, but dies on "mke2fs". Running mke2fs through strace shows
> that it stops during the early stages, before it even tries to write
> anything. mke2fs appears to seek through the whole device and do a bunch
> of small reads at various points, and as soon as it tries to read from an
> offset > 2 TB, it hangs.
It sounds like mke2fs tried using BLKGETSIZE ioctl, but given that
this returns the number of 512 byte sectors in a device in a 4 byte
word, the BLKGETSIZE ioctl quite rightly threw up its hands and said,
"sorry, I can't tell you the correct size."
The mke2fs fell back to its backup algorithm, which uses a modified
binary search to find the size of the device. It started to see if
the device was at least 1k, and checks to see if the device is at
least 2k, 4k, 8k, 16k, 32k, 64k, 128k, etc. So it sounds like it's
dieing when it tries to seek past 2TB using llseek().
It would probably be worthwhile to write a little test program which
opens the disk, llseeks to 2TB+1, and then tries reading a byte. If
that fiailes, then there's definitely a bug somewhere in the device
driver....
- Ted
next prev parent reply other threads:[~2003-12-05 6:55 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-01 14:06 Reproducable OOPS with MD RAID-5 on 2.6.0-test11 Kevin P. Fleming
2003-12-01 14:11 ` Jens Axboe
2003-12-01 14:15 ` Kevin P. Fleming
2003-12-01 15:51 ` Jens Axboe
2003-12-02 4:02 ` Kevin P. Fleming
2003-12-02 4:15 ` Mike Fedyk
2003-12-02 13:11 ` Kevin P. Fleming
2003-12-02 8:27 ` Jens Axboe
2003-12-02 10:10 ` Nathan Scott
2003-12-02 13:15 ` Kevin P. Fleming
2003-12-03 3:32 ` Nathan Scott
2003-12-03 17:13 ` Linus Torvalds
2003-12-02 18:23 ` Linus Torvalds
2003-12-04 1:12 ` Simon Kirby
2003-12-04 1:23 ` Linus Torvalds
2003-12-04 4:31 ` Simon Kirby
2003-12-05 6:55 ` Theodore Ts'o [this message]
2003-12-04 20:53 ` Herbert Xu
2003-12-04 21:06 ` Linus Torvalds
2003-12-01 23:06 ` Reproducable OOPS with MD RAID-5 on 2.6.0-test11 - with XFS Neil Brown
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=20031205065522.GA28825@thunk.org \
--to=tytso@mit.edu \
--cc=axboe@suse.de \
--cc=kpfleming@backtobasicsmgmt.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-lvm@sistina.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=sim@netnation.com \
--cc=torvalds@osdl.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;
as well as URLs for NNTP newsgroup(s).