From: Andries Brouwer <aebr@win.tue.nl>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andries.Brouwer@cwi.nl, <linux-kernel@vger.kernel.org>,
<linux-raid@vger.kernel.org>, <neilb@cse.unsw.edu.au>
Subject: Re: PATCH - change to blkdev->queue calling triggers BUG in md.c
Date: Tue, 3 Sep 2002 01:08:24 +0200 [thread overview]
Message-ID: <20020902230824.GB9359@win.tue.nl> (raw)
In-Reply-To: <Pine.LNX.4.44.0209021459030.1401-100000@home.transmeta.com>
On Mon, Sep 02, 2002 at 03:00:27PM -0700, Linus Torvalds wrote:
> > No, my suggested changes would not break a single Linux installation
> > in the world.
>
> .. by making your suggested behaviour not be used. Yes.
Not so pessimistic. We go by small steps.
I think it important to get rid of partition table reading in the kernel.
It (pt reading) is wrong in principle, as we agree already.
But there are also all kinds of practical reasons.
One argument is that our traditional DOS-type partition table will soon
be at the end of its useful life. Yes, maybe it survives a few more years
but our own stability requires slow changes, so we must start thinking a
long time in advance.
Another argument is that it sometimes takes a *long* time, like several
minutes, especially when this reading triggers hardware bugs.
Another argument is that nobody knows whether there is a partition table.
In the case of ZIP drives there sometimes is a jumper or special SCSI command
to switch between the "large floppy" and "removable disk" statuses, and
the kernel doesnt know.
Another argument is that tricky things happen in the presence of disk managers.
So stage one is a kernel boot parameter "nopt" or so, that stops parsing
of partition tables other than the root partition. Some people need it
because of special problems, others just want to experiment. That is good,
and we'll get some feedback on partx and family.
Stage two happens a year later, when we have a working initrd. Seen from the
outside the new (kernel + initrd) plays the role of the old kernel.
Ha. That means that we can move the pt reading to initrd, and nobody notices.
Stage three happens when initrd and kernel no longer are so tightly coupled.
Initrd is just early userspace, tools exist to populate it, distributions make
their own. Now the kernel does not need any partition reading code and
nobody ever noticed. And the setup has become much more powerful.
-----
> But if that is the case, then we _still_ need to fix the media change and
> partition read issue. Right? Which brings back _all_ my points for why it
> should be done at open time, and by the generic routine. Agreed?
The above was mainly about the partition reading at boot time.
There are two other situations: partition reading at insmod time,
and partition reading at media change time.
But these are easier situations. There is a functioning userspace already.
As I said, in view of the desired direction, I would not mind at all if
a media change did not trigger partition reading today.
(In fact, for me, under 2.5.33, it doesn't. But blockdev --rereadpt helps.)
Andries
next prev parent reply other threads:[~2002-09-02 23:03 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-02 21:41 Andries.Brouwer
2002-09-02 22:00 ` Linus Torvalds
2002-09-02 23:08 ` Andries Brouwer [this message]
2002-09-02 23:27 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2002-09-03 0:53 Andries.Brouwer
2002-09-03 3:55 ` Linus Torvalds
2002-09-03 4:06 ` Linus Torvalds
2002-09-03 15:22 ` Andries Brouwer
2002-09-02 21:27 Andries.Brouwer
2002-09-02 21:39 ` Linus Torvalds
2002-09-02 21:48 ` Thunder from the hill
2002-09-02 21:43 ` Thunder from the hill
2002-09-02 21:58 ` Andries Brouwer
2002-09-02 22:06 ` Linus Torvalds
2002-09-02 22:39 ` Thunder from the hill
2002-09-02 22:33 ` Hacksaw
2002-09-02 22:57 ` Oliver Neukum
2002-09-02 23:27 ` Hacksaw
2002-09-03 17:23 ` Thunder from the hill
2002-09-03 18:04 ` Hacksaw
2002-09-03 19:38 ` Thunder from the hill
2002-09-03 20:20 ` Hacksaw
2002-09-03 20:34 ` Thunder from the hill
2002-09-03 20:45 ` Alan Cox
2002-09-03 20:55 ` Thunder from the hill
2002-09-03 21:59 ` Alan Cox
2002-09-03 22:03 ` Thunder from the hill
2002-09-04 0:08 ` Oliver Neukum
2002-09-04 5:50 ` Thunder from the hill
2002-09-03 20:50 ` Hacksaw
2002-09-03 21:05 ` Thunder from the hill
2002-09-03 21:32 ` Hacksaw
2002-09-03 21:51 ` Thunder from the hill
2002-09-04 8:02 ` Giuliano Pochini
2002-09-02 8:53 Andries.Brouwer
2002-09-02 17:01 ` Linus Torvalds
2002-09-02 20:35 ` Andries Brouwer
2002-09-02 20:50 ` Linus Torvalds
2002-09-01 23:43 Neil Brown
2002-09-02 4:13 ` Linus Torvalds
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=20020902230824.GB9359@win.tue.nl \
--to=aebr@win.tue.nl \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@cse.unsw.edu.au \
--cc=torvalds@transmeta.com \
/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®