Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754906AbYABSPj (ORCPT ); Wed, 2 Jan 2008 13:15:39 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752507AbYABSPc (ORCPT ); Wed, 2 Jan 2008 13:15:32 -0500 Received: from mail.tmr.com ([64.65.253.246]:34261 "EHLO gaimboi.tmr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752339AbYABSPb (ORCPT ); Wed, 2 Jan 2008 13:15:31 -0500 Message-ID: <477BD9DA.8030403@tmr.com> Date: Wed, 02 Jan 2008 13:37:14 -0500 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.8) Gecko/20061105 SeaMonkey/1.0.6 MIME-Version: 1.0 To: Jan Engelhardt CC: Gene Heskett , linux-kernel@vger.kernel.org Subject: Re: semi-regular plea for stable device mapping References: <200801011054.40512.gene.heskett@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1911 Lines: 41 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 "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/