FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 09-02-2008, 10:36 AM
"Alan D. Brunelle"
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 10:47 AM
Tejun Heo
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

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

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 10:55 AM
"Alan D. Brunelle"
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

Tejun Heo wrote:
> 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.

Then perhaps it should /not/ default to Y...

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


No, but knowing the upper bound would be helpful.


>
> Thanks.
>

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 10:57 AM
Jens Axboe
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

On Tue, Sep 02 2008, Alan D. Brunelle wrote:
> Tejun Heo wrote:
> > 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.
>
> Then perhaps it should /not/ default to Y...

It has already been changed to default to 'n'.

--
Jens Axboe

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 11:06 AM
Tejun Heo
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

Alan D. Brunelle wrote:
>>> (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?
>
> No, but knowing the upper bound would be helpful.

Well, dev_t is 32bits and MINORBITS is 20. So, major 12 bits, minor 20
bits, so 4 characters for major, 7 characters for minor.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 12:20 PM
Alasdair G Kergon
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

On Tue, Sep 02, 2008 at 01:06:24PM +0200, Tejun Heo wrote:
> Well, dev_t is 32bits and MINORBITS is 20. So, major 12 bits, minor 20
> bits, so 4 characters for major, 7 characters for minor.

Upstream libdevmapper CVS patched - will appear in next release (1.02.28).

Alasdair
--
agk@redhat.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 09-02-2008, 12:23 PM
Tejun Heo
 
Default Problem w/ CONFIG_DEBUG_BLOCK_EXT_DEVT

Alasdair G Kergon wrote:
> On Tue, Sep 02, 2008 at 01:06:24PM +0200, Tejun Heo wrote:
>> Well, dev_t is 32bits and MINORBITS is 20. So, major 12 bits, minor 20
>> bits, so 4 characters for major, 7 characters for minor.
>
> Upstream libdevmapper CVS patched - will appear in next release (1.02.28).

Alright, thanks. What about the /proc/devices one? Would adding an
entry help? I'm kind of lost /proc/devices. It's now mostly
non-functional legacy stuff we've been carrying around. Is it
deprecated or do we intend to keep it around forever?

Ooh.. which also reminds me that I forgot to reserve the major number w/
lanana. Will do that.

Thanks.

--
tejun

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 06:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org