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
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.
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 <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot