semi-regular plea for stable device mapping

semi-regular plea for stable device mapping

[Gene Heskett]

Greetings;

Yesterday I built a new kernel with most of the disk driver stuff built in.  
It boots, I'm running it now, and I now have the libata stuff being detected 
by the kernel at boot time in the same order as an F8 distro kernel does.

BUT!  This defeats a fix I've had in my modprobe.conf for over a year now that 
gave the LVM stuff a stable major device # of 238, and now my LVM major is 
back to whatever mood the kernel is in, in this particular bootup case to 
#253.

It may now be stable for a bit at that number because I see that pktcdvd has 
been given a stable address of its own, apparently with a major of 10.  That 
was the wedgie that fscked things up originally for me.  But what else lurks 
in the deep end of this experimental pool, to play piranna with us again when 
we least expect it?

IMO we've been using LVM stuffs now for a long enough period that it should 
lose its experimental status, which apparently means its enumerated from 255 
down when found, getting the first vacant address and dependent on whats 
found before it, the major number can change on a per boot basis, just for 
something as innocent as plugging in a usb hard drive enclosure.

This drives tar up a wall because it uses this device number as part of the 
file comparisons it does, and it thinks everything is therefore new and needs 
a full level 0 backup.  This is not at all practical, and requires that 
amanda be re-run many times in the next day in order for the backups to catch 
up with reality & completely confuses any scheduling amanda may have worked 
out that assure a smooth backup every night.  Litterally it can take weeks 
for this schedule to return to some semblance of smooth operation with about 
the same size of backups being done every night.

The tar people have to deal with many platforms and are convinced their method 
is the correct one, so they aren't going to change that aspect of how tar 
works just to satisfy a linux user.

To me, it seems like it is time to pull this LVM stuff out of the LANANA(sp?) 
experimental category and give it a stable home.  This should be a New Years 
Resolution for linux. :-)

In the meantime, how can I specify a major of 238 for dm-mod when its built 
in, given as an argument on the kernel command line in a grub boot stanza?

Being able to do that would give me back stable addressing for tar to work 
from.

Thanks, and I hope the 'Happy New Year' hangovers are recoverable.

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
hardware stress fractures

Re: semi-regular plea for stable device mapping

[Jan Engelhardt]

On Jan 1 2008 10:54, Gene Heskett wrote:
>
>BUT!  This defeats a fix I've had in my modprobe.conf for over a year now that 
>gave the LVM stuff a stable major device # of 238, and now my LVM major is 
>back to whatever mood the kernel is in, in this particular bootup case to 
>#253.
>
>It may now be stable for a bit at that number because I see that pktcdvd has 
>been given a stable address of its own, apparently with a major of 10.  That 
>was the wedgie that fscked things up originally for me.  But what else lurks 
>in the deep end of this experimental pool, to play piranna with us again when 
>we least expect it?

Why exactly would you require a fixed major - not running udev or thelike?
Use the boot parameter, dm_mod.major=238.

>This drives tar up a wall because it uses this device number as part of the 
>file comparisons it does, and it thinks everything is therefore new and needs 
>a full level 0 backup.  This is not at all practical, and requires that 

I wonder how FreeBSD gets around this, because they've got dynamic numbers
everywhere.

Re: semi-regular plea for stable device mapping

[Bill Davidsen]

Jan Engelhardt wrote:
> On Jan 1 2008 10:54, Gene Heskett wrote:
>> BUT!  This defeats a fix I've had in my modprobe.conf for over a year now that 
>> gave the LVM stuff a stable major device # of 238, and now my LVM major is 
>> back to whatever mood the kernel is in, in this particular bootup case to 
>> #253.
>>
>> It may now be stable for a bit at that number because I see that pktcdvd has 
>> been given a stable address of its own, apparently with a major of 10.  That 
>> was the wedgie that fscked things up originally for me.  But what else lurks 
>> in the deep end of this experimental pool, to play piranna with us again when 
>> we least expect it?
> 
> Why exactly would you require a fixed major - not running udev or thelike?
> Use the boot parameter, dm_mod.major=238.
> 
What? And what happens when that gets used for something else? And if 
you say "we'll avoid using that" then you are treating it as a fixed 
value anyway.

>> This drives tar up a wall because it uses this device number as part of the 
>> file comparisons it does, and it thinks everything is therefore new and needs 
>> a full level 0 backup.  This is not at all practical, and requires that 
> 
> I wonder how FreeBSD gets around this, because they've got dynamic numbers
> everywhere.

Did they? I haven't tried using tar in the appropriate ways on BSD to 
see if it behaves in the same way. Of course on a system which doesn't 
change between backups I guess the dynamic number would be the same in 
any case.

-- 
Bill Davidsen <davidsen@tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot