linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	tj@kernel.org
Subject: Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT
Date: Tue, 02 Sep 2008 06:36:43 -0400	[thread overview]
Message-ID: <48BD173B.3090600@hp.com> (raw)

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)

"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.

(2) Device minor numbers can be quite large, and the 10-character limits
in dm/lib/libdm-deptree.c are too small.

Alan

             reply	other threads:[~2008-09-02 10:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-02 10:36 Alan D. Brunelle [this message]
2008-09-02 10:47 ` Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT Tejun Heo
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       ` [dm-devel] " Alasdair G Kergon
2008-09-02 12:23         ` 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=48BD173B.3090600@hp.com \
    --to=alan.brunelle@hp.com \
    --cc=dm-devel@redhat.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tj@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;
as well as URLs for NNTP newsgroup(s).