From: Tejun Heo <tj@kernel.org>
To: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
Cc: device-mapper development <dm-devel@redhat.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Jens Axboe <jens.axboe@oracle.com>
Subject: Re: Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT
Date: Tue, 02 Sep 2008 12:47:13 +0200 [thread overview]
Message-ID: <48BD19B1.9040207@kernel.org> (raw)
In-Reply-To: <48BD173B.3090600@hp.com>
Hello,
Alan D. Brunelle wrote:
> I have found two problems in LVM2/DM w/ a potential new "experimental
> feature" in 2.6.28: CONFIG_DEBUG_BLOCK_EXT_DEVT (this is from Jens
> Axboe's origin/for-2.6.28 git branch)
It's a debug option and I don't expect it to be enabled in any
production kernel.
> "Conventionally, block device numbers are allocated from predetermined
> contiguous area. However, extended block area may introduce
> non-contiguous block device numbers. This option forces most block
> device numbers to be allocated from the extended space and spreads them
> to discover kernel or userland code paths which assume predetermined
> contiguous device number allocation."
>
> W/ LVM2 & DM there are (at least) two issues:
>
> (1) Device major numbers for some reason are /not/ being entered
> correctly into /proc/devices -- w/ CONFIG_DEBUG_BLOCK_EXT_DEVT=y I am
> seeing some devices w/ major "259" (a SATA controller) but no entry in
> /proc/devices. LVM2/DM will not find the entry in /proc/devices, and not
> allow any device w/ that major to be used with LVM commands.
Hmmm.. Adding a call to register_blkdev(), which will create the
corresponding entry in /proc/devices, isn't difficult at all but which
name would it use? It'll be mix of block devices (hd and sds
currently). If we introduce a new name there, say, ext-block, would
that work? BTW, is there any specific reason why LVM2/DM can't use
/sys/block/* ?
> (2) Device minor numbers can be quite large, and the 10-character limits
> in dm/lib/libdm-deptree.c are too small.
Would it be difficult to increase that?
Thanks.
--
tejun
next prev parent reply other threads:[~2008-09-02 10:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-02 10:36 Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT Alan D. Brunelle
2008-09-02 10:36 ` Alan D. Brunelle
2008-09-02 10:47 ` Tejun Heo [this message]
2008-09-02 10:55 ` Alan D. Brunelle
2008-09-02 10:57 ` Jens Axboe
2008-09-02 11:06 ` Tejun Heo
2008-09-02 12:20 ` Alasdair G Kergon
2008-09-02 12:20 ` [dm-devel] " Alasdair G Kergon
2008-09-02 12:23 ` Tejun Heo
2008-09-02 12:23 ` [dm-devel] " Tejun Heo
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=48BD19B1.9040207@kernel.org \
--to=tj@kernel.org \
--cc=Alan.Brunelle@hp.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.