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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 04 Apr 2007 20:49:19 -0400
From:	Gene Heskett <gene.heskett@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	Dave Dillow <dave@...dillows.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, ray-gmail@...rabbit.org,
	amanda-hackers@...nda.org, amanda-users@...nda.org
Subject: Re: plain 2.6.21-rc5 (1) vs amanda (0)

On Wednesday 04 April 2007, Dave Dillow wrote:
>On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
>> On Wed, 04 Apr 2007 14:17:13 -0400
>>
>> Dave Dillow <dave@...dillows.org> wrote:
>> > 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?
>>
>> hm, good points.
>>
>> Overall, the patch helps kernel developers and hurts the userbase.  I
>> tend to prefer to hurt kernel developers than our users ;)
>>
>> I don't think the protect-lanana-numbers thing is very important,
>> really. If some kernel developer or someone who is maintaining an
>> unofficial out-of-tree driver hits the problem, they are presumably
>> able to handle it.  Preferably by switching to a dynamically-assigned
>> major.
>
>Works for me; I don't really have a dog in the fight.

I do, but now that I know that the problem is, and why the fix was done, 
I'm ambivalent as to how it should be fixed.  In this case the dog 
getting bit is tar (I have NDI if dump is also effected as I don't use 
it), and I would rather see tar made immune to the effects of a patch 
that was originally made to correct practice into a little closer to what 
the preacher said.

I see the facts as:
 1. the name of the directory didn't change,
 2. the inode contents aren't (ANAICT) modified in any way, and
 3. the file is still the file it was back in July of last year when I 
wrote it.

Perhaps someone can explain to me why tar thinks its all new just because 
the mapper was spanked and made to be a good puppy?

In my mind at least, its tar that has the egg on its face, and its tar 
that needs to be immunized.  Can someone tell me where am I wrong?

I'd really like to know why there is an apparent connection between this, 
and tars response, which is to think the whole disk is new and has to 
have a level 0 backup all over again.

-- 
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)
If God had a beard, he'd be a UNIX programmer.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/