creating partition mappings with different delimiters

creating partition mappings with different delimiters

[Eddie Williams]

Where/how does kpartx determine the default delimiter when creating the
partition mappings and nodes?

With Red Hat EL 4 Update 3 during bootup the partition mappings are
getting created in rc.sysinit.  However I find that some of the mappings
have no delimiter while some have 'p' as the delimiter.  I prefer 'p' as
the delimiter.

I have been unsuccessful at finding where kpartx (or is it dmsetup) is
determining what delimiter to use.

Eddie

Re: creating partition mappings with different delimiters

[Eddie Williams]

I see it is kpartx that is defaulting to the 'p' as the delimiter (in
the set_delimiter function) when the uuid ends with a digit and no
delimiter when the uuid ends with a character.

Wouldn't it be better to always use the same delimiter by default?  As
it stands now one will not be able to determine that a node is a
partition versus a full device by just looking at the name. 

Eddie
On Mon, 2006-04-03 at 12:19 -0400, Eddie Williams wrote:
> Where/how does kpartx determine the default delimiter when creating the
> partition mappings and nodes?
> 
> With Red Hat EL 4 Update 3 during bootup the partition mappings are
> getting created in rc.sysinit.  However I find that some of the mappings
> have no delimiter while some have 'p' as the delimiter.  I prefer 'p' as
> the delimiter.
> 
> I have been unsuccessful at finding where kpartx (or is it dmsetup) is
> determining what delimiter to use.
> 
> Eddie
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

Re: creating partition mappings with different delimiters

[Christophe Varoqui]

Eddie Williams a écrit :
> I see it is kpartx that is defaulting to the 'p' as the delimiter (in
> the set_delimiter function) when the uuid ends with a digit and no
> delimiter when the uuid ends with a character.
>
> Wouldn't it be better to always use the same delimiter by default?  As
> it stands now one will not be able to determine that a node is a
> partition versus a full device by just looking at the name. 
>
>   
This behaviour mimics the kernel partition naming policies : /dev/sd? 
partitions have no separator, while /dev/cciss/c0d0 have one, for example.

kpartx once meant to be a true alternative to in-kernel partition 
handling, thus cared about that naming compatibility.

I'm inclined to leave it that way, if not only to discourage people to 
partition multipathed devices :)

Regards,
cvaroqui

Re: creating partition mappings with different delimiters

[Philip R. Auld]

Hi,

Rumor has it that on Mon, Apr 03, 2006 at 11:23:18PM +0200 Christophe Varoqui said:
> I'm inclined to leave it that way, if not only to discourage people to 
> partition multipathed devices :)
> 

Why do you want to discourage partitioning multipath devices? That
seems to me to be a requirement. 


Cheers,

Phil



> Regards,
> cvaroqui
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

Re: creating partition mappings with different delimiters

[Eddie Williams]

On Mon, 2006-04-03 at 23:23 +0200, Christophe Varoqui wrote:
> Eddie Williams a écrit :
> > I see it is kpartx that is defaulting to the 'p' as the delimiter (in
> > the set_delimiter function) when the uuid ends with a digit and no
> > delimiter when the uuid ends with a character.
> >
> > Wouldn't it be better to always use the same delimiter by default?  As
> > it stands now one will not be able to determine that a node is a
> > partition versus a full device by just looking at the name. 
> >
> >   
> This behaviour mimics the kernel partition naming policies : /dev/sd? 
> partitions have no separator, while /dev/cciss/c0d0 have one, for example.

Yes and no.  Yes, for /dev/sd nodes it never adds a separator and
for /dev/cciss it always adds one.  But "no" in the sense that I can not
think of any examples prior to this where sometimes it does and
sometimes it doesn't (add a separator) for the same device type.

The key item here is that it was consistent.  For each device you knew
what to expect.  That made for a nice easy regular expression to figure
out what kind of device you were dealing with.

For the case of "uuid" nodes I do not see a way to use a regular
expression to determine what kind of node you are dealing with.  If you
have a node that ends with something like "c1" you can not tell if that
is partition 1 or the full device.

Yes, there are tools available to figure out if a node is a partition or
the full disk.  I have to admit to being lazy and like the ease at being
able at a glance to tell what the node represents.  The same work I do
not want to have to do as a human I also do not want to have to add to
my programs.  I often find being lazy makes for good programming.
Accomplishing a task with minimal work is always best (and even better
if you find someone else has done the work for you).

> 
> kpartx once meant to be a true alternative to in-kernel partition 
> handling, thus cared about that naming compatibility.
> 
> I'm inclined to leave it that way, if not only to discourage people to 
> partition multipathed devices :)

I can understand that, I was a bit disappointed when I found that kpartx
existed.  I was not expecting to support partitions on multipath
devices.  The cat is out of the bag now and I doubt it will go back in.
Partitions are here to stay.

I started to suggest that I could add a way, perhaps in multipath.conf,
to define a default separator.  That way someone could override the
default behavior fairly easily.  I am not sure making this change now is
worth it though.  I will just accept that I probably need to run
'dmsetup info' on a node to figure out if it is a partition or disk.

Thanks

Eddie

 

Re: creating partition mappings with different delimiters

[Eddie Williams]

On Tue, 2006-04-04 at 09:24 -0400, Philip R. Auld wrote:
> Hi,
> 
> Rumor has it that on Mon, Apr 03, 2006 at 11:23:18PM +0200 Christophe Varoqui said:
> > I'm inclined to leave it that way, if not only to discourage people to 
> > partition multipathed devices :)
> > 
> 
> Why do you want to discourage partitioning multipath devices? That
> seems to me to be a requirement. 

It seems to me that volume managers, aka LVM or the like, is where folks
should be heading and the faster we can move them in that direction the
better.  The volume managers provide so much more flexibility than
partitions.

Eddie

Re: creating partition mappings with different delimiters

[Philip R. Auld]

Rumor has it that on Tue, Apr 04, 2006 at 09:36:23AM -0400 Eddie Williams said:
> On Tue, 2006-04-04 at 09:24 -0400, Philip R. Auld wrote:
> > Hi,
> > 
> > Rumor has it that on Mon, Apr 03, 2006 at 11:23:18PM +0200 Christophe Varoqui said:
> > > I'm inclined to leave it that way, if not only to discourage people to 
> > > partition multipathed devices :)
> > > 
> > 
> > Why do you want to discourage partitioning multipath devices? That
> > seems to me to be a requirement. 
> 
> It seems to me that volume managers, aka LVM or the like, is where folks
> should be heading and the faster we can move them in that direction the
> better.  The volume managers provide so much more flexibility than
> partitions.
> 

Maybe so. But they also add another layer of complexity for
booting. I'd like the steps between me and a successful boot 
to be as complex as required but no more so.

Cheers,

Phil



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

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

Re: creating partition mappings with different delimiters

[Christophe Varoqui]

>> It seems to me that volume managers, aka LVM or the like, is where folks
>> should be heading and the faster we can move them in that direction the
>> better.  The volume managers provide so much more flexibility than
>> partitions.
>>
>>     
>
> Maybe so. But they also add another layer of complexity for
> booting. I'd like the steps between me and a successful boot 
> to be as complex as required but no more so.
>
>   
True, just as the whole SAN is just another layer layer of complexity 
for booting and swaping : zoning and selective storage presentation 
errors are common, not to mention software shortcomings.

System on SAN is just a bit more risky. Not doing it also cuts down on 
the main use for partitions.

Big data volumes can be handled just fine by storage arrays internal 
volume managers.

My opinions, anyway.
So subject to frequent oscillations ;)

Regards,
cvaroqui

Re: creating partition mappings with different delimiters

[Philip R. Auld]

Hi Christophe,

Rumor has it that on Tue, Apr 04, 2006 at 07:49:49PM +0200 Christophe Varoqui said:
> 
> >>It seems to me that volume managers, aka LVM or the like, is where folks
> >>should be heading and the faster we can move them in that direction the
> >>better.  The volume managers provide so much more flexibility than
> >>partitions.
> >>
> >>    
> >
> >Maybe so. But they also add another layer of complexity for
> >booting. I'd like the steps between me and a successful boot 
> >to be as complex as required but no more so.
> >
> >  
> True, just as the whole SAN is just another layer layer of complexity 
> for booting and swaping : zoning and selective storage presentation 
> errors are common, not to mention software shortcomings.
> 
> System on SAN is just a bit more risky. Not doing it also cuts down on 
> the main use for partitions.
> 

That's exactly what I need. My servers are diskless and have system 
on SAN (by way of virtualized SCSI). I'm hoping to move to using 
dm-multipath in the future. But will need to make it work as
painlessly (and transparently) as possible for the root disk right 
out of the box. 

The SAN based root disk is part of what allows for stateless blades.
But it's not good to lose the only path the your root disk :)


Cheers,

Phil


> Big data volumes can be handled just fine by storage arrays internal 
> volume managers.
> 
> My opinions, anyway.
> So subject to frequent oscillations ;)
> 
> Regards,
> cvaroqui
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

-- 
Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752