Re: plain 2.6.21-rc5 (1) vs amanda (0)

[Dave Dillow]

On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
> On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <mingo@xxxxxxx> wrote:
> 
> > 
> > * Dave Dillow <dave@xxxxxxxxxxxxxx> wrote:
> > 
> > > > Then it is a matter of figuring out why the device number changed -- 
> > > > I'm thinking it is device-mapper, but will look closer tomorrow.
> > > 
> > > This commit is the one that changed it:
> > > 
> > > commit fdf892be32d84a1745fa0aee5fc60517421b8038
> > > Author: Andrew Morton <akpm@xxxxxxxx>
> > > Date:   Mon Feb 12 00:51:44 2007 -0800
> > > 
> > >     [PATCH] register_blkdev(): don't hand out the LOCAL/EXPERIMENTAL majors
> > >     
> > >     As pointed out in http://bugzilla.kernel.org/show_bug.cgi?id=7922, 
> > >     dynamic blockdev major allocation can hand out majors which LANANA 
> > >     has defined as being for local/experimental use.
> > 
> > i dont think we should break backwards compatibility with a system that 
> > has not changed any hardware. Andrew, should we revert this?
> 
> Well that's an odd thing for a backup program to be doing - there are any
> number of things which could cause a dynamically-allocated major to change.
> 
> ho hum, yes, I guess it needs to go.

The thing is, it's been broken for a long time -- this change just
highlighted it. This isn't the first time that device-mapper has moved
-- the introduction of mdp (before git, so haven't tracked down
timeframe) also moved it around. The dynamic major is not stable, so
should we be concerned if it moves for 2.6.21?

I don't like the effect it has on the backups, but I don't think we
should hand out LOCAL/EXP majors to dynamic devices, either. There is a
module option to make the device-mapper and mdp majors stable, so
perhaps a compromise is possible? Revert for 2.6.21, and schedule the
patch for later addition, which gives distros time to use the DM major
option?
-- 
Dave Dillow <dave@xxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/