LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* plain 2.6.21-rc5 (1) vs amanda (0)
@ 2007-04-01  5:00 Gene Heskett
  2007-04-01  6:51 ` Ingo Molnar
  2007-04-01  7:33 ` Ray Lee
  0 siblings, 2 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-01  5:00 UTC (permalink / raw)
  To: Ingo Molnar, amanda-hackers, linux-kernel, amanda-users

Hi Ingo;

Running 2.6.21-rc5 tonight.

It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in its
version string) amanda is still a loser.
>From an amstatus report as the back up is just getting started, 
and amanda has completed the estimates:

[root@coyote Daily]# amstatus Daily
Using /usr/local/var/amanda/Daily/amdump from Sun Apr  1 00:05:04 EDT 2007

coyote:/GenesAmandaHelper-0.5 1 planner: [dumps way too big, 156684 KB, must skip incremental dumps]
coyote:/GenesAmandaHelper-0.6 4 planner: [dumps way too big, 780226 KB, must skip incremental dumps]
coyote:/bin                   1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/boot                  1        3m wait for dumping
coyote:/dev                   0        0m wait for dumping
coyote:/etc                   2 planner: [dumps way too big, 18533 KB, must skip incremental dumps]
coyote:/home                  0      858m wait for dumping
coyote:/lib                   1 planner: [dumps way too big, 100080 KB, must skip incremental dumps]
coyote:/opt                   1     2192m wait for dumping
coyote:/root                  2 planner: [dumps way too big, 1684448 KB, must skip incremental dumps]
coyote:/sbin                  1        0m wait for dumping
coyote:/tmp                   1 planner: [dumps way too big, 8972 KB, must skip incremental dumps]
coyote:/usr/X11R6             1 planner: [dumps way too big, 232 KB, must skip incremental dumps]
coyote:/usr/bin               1 planner: [dumps way too big, 26030 KB, must skip incremental dumps]
coyote:/usr/dlds              1 planner: [dumps way too big, 93030 KB, must skip incremental dumps]
coyote:/usr/dlds-misc         2      155m wait for dumping
coyote:/usr/dlds-rpms         1 planner: [dumps way too big, 10 KB, must skip incremental dumps]
coyote:/usr/dlds-tgzs         1        0m wait for dumping
coyote:/usr/games             0        0m wait for dumping
coyote:/usr/include           1       85m wait for dumping
coyote:/usr/kerberos          1 planner: [dumps way too big, 1360 KB, must skip incremental dumps]
coyote:/usr/lib               3 planner: [dumps way too big, 337013 KB, must skip incremental dumps]
coyote:/usr/libexec           1 planner: [dumps way too big, 20138 KB, must skip incremental dumps]
coyote:/usr/local             1 planner: [dumps way too big, 42374 KB, must skip incremental dumps]
coyote:/usr/man               1 planner: [dumps way too big, 710 KB, must skip incremental dumps]
coyote:/usr/movies            1     7271m dumping     5298m ( 72.87%) (0:12:48)
coyote:/usr/music             1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps]
coyote:/usr/pix               1 planner: [dumps way too big, 856480 KB, must skip incremental dumps]
coyote:/usr/sbin              1 planner: [dumps way too big, 2305 KB, must skip incremental dumps]
coyote:/usr/share             2 planner: [dumps way too big, 348843 KB, must skip incremental dumps]
coyote:/usr/src               1 planner: [dumps way too big, 2519056 KB, must skip incremental dumps]
coyote:/var                   3     3774m wait for dumping

SUMMARY          part      real  estimated
                           size       size
partition       :  32
estimated       :  32                42307m
flush           :   0         0m
failed          :  21                27964m           ( 66.10%)
wait for dumping:  10                 7070m           ( 16.71%)
dumping to tape :   0                    0m           (  0.00%)
dumping         :   1      5298m      7271m ( 72.87%) ( 12.52%)
dumped          :   0         0m         0m (  0.00%) (  0.00%)
wait for writing:   0         0m         0m (  0.00%) (  0.00%)
wait to flush   :   0         0m         0m (100.00%) (  0.00%)
writing to tape :   0         0m         0m (  0.00%) (  0.00%)
failed to tape  :   0         0m         0m (  0.00%) (  0.00%)
taped           :   0         0m         0m (  0.00%) (  0.00%)
  tape 1        :   0         0m         0m (  0.00%) Dailys-17
8 dumpers idle  : not-idle
taper idle
network free kps:      6800
holding space   :     66234m (100.00%)
 dumper0 busy   :  0:00:00  (  0.00%)
 0 dumpers busy :  0:00:00  (  0.00%)
 1 dumper busy  :  0:00:00  (  0.00%)
[root@coyote Daily]#  

Anything above that's 'way too big' is within a percent or so, regardless
of the level, of a full, every byte backup.  The number in column 31 above
is the backup level that disklist entry is getting right now.
 
As a sample of how it is being messed with, for a single, approximately 2.5GB 
collection of music I have, are the outputs of the sendsize function
for the last 2 runs, yesterdays dated files were obtained running 2.6.20.4
and todays were obtained with 2.6.21-rc5.

Good, 2.6.20.4 was running
sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting size via gnutar for /usr/music level 0
sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level 0: 1.239
sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music level 0: 2466050 KB
sendsize.20070331000507.debug:sendsize[762]: time 249.605: getting size via gnutar for /usr/music level 1
sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level 1: 0.027
sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music level 1: 80 KB

Bad, 2.6.21-rc5 is running
sendsize.20070401000504.debug:sendsize[18465]: time 167.371: getting size via gnutar for /usr/music level 0
sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music level 0: 0.398
sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music level 0: 2466050 KB
sendsize.20070401000504.debug:sendsize[18465]: time 167.773: getting size via gnutar for /usr/music level 1
sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music level 1: 0.049
sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music level 1: 2448290 KB

Yesterdays run, dated 20070331000507 were correct as that directory hasn't been
write accessed in a couple of months.

Today's, dated 20070401000504, shows totally bogus figures for exactly 
the same data.

This effect I have isolated down to something in the 31 patches from
2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
setting up the bisect to find it.  If indeed its a kernel problem.

This same effect has been present in any and every 2.6.21.* release.

Now, strange it seems, the outputs of the ls command which show these
timestamps that amanda and in this case tar supposedly uses to
determine whats new and changed since the last backup run (as determined
by the dates and levels stored in the /etc/amandates file) are completely
sane unless I'm using them wrong.  Somebody might want to make sure I'm
doing that right.

I've also filed a bz entry in the redhat/fedora bugzilla against the rpm 
of tar supplied with an uptodate FC6, but so far in 2 weeks, the activity
there has been nill, zip, ignored.

I personally think its a tar problem but can't manage to find enough data
to be able to nail that blob of jelly to the tree.

What I do know is that this IS a showstopper for amanda, the backup utility.

The manpages for tar haven't been touched since 1.14, and the (p)info entries
I'd almost erase for lack of info, so if someone can tell me how to
construct a tar command line that will make tar give me a size answer
for whats new since timestamp yyyymmddhhmmss I'd have yet another tool
to use as a finger pointer that would carry some weight amongst the
non-believers here.

-- 
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)
When I sell liquor, it's called bootlegging; when my patrons serve
it on silver trays on Lake Shore Drive, it's called hospitality.
		-- Al Capone

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-01  5:00 plain 2.6.21-rc5 (1) vs amanda (0) Gene Heskett
@ 2007-04-01  6:51 ` Ingo Molnar
  2007-04-01 14:44   ` Gene Heskett
  2007-04-01  7:33 ` Ray Lee
  1 sibling, 1 reply; 22+ messages in thread
From: Ingo Molnar @ 2007-04-01  6:51 UTC (permalink / raw)
  To: Gene Heskett
  Cc: amanda-hackers, linux-kernel, amanda-users, Andrew Morton, Adrian Bunk


* Gene Heskett <gene.heskett@verizon.net> wrote:

> Hi Ingo;
> 
> Running 2.6.21-rc5 tonight.
> 
> It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in 
> its version string) amanda is still a loser. [...]

here 'is a loser' means: "tries to back up way too much stuff instead of 
doing a nice incremental backup like it does on 2.6.20.4", correct?

since it appears to be caused by a kernel change, this is a serious 
regression in v2.6.21-to-be.

> Good, 2.6.20.4 was running
> sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting size via gnutar for /usr/music level 0
> sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level 0: 1.239
> sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music level 0: 2466050 KB
> sendsize.20070331000507.debug:sendsize[762]: time 249.605: getting size via gnutar for /usr/music level 1
> sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level 1: 0.027
> sendsize.20070331000507.debug:sendsize[762]: estimate size for /usr/music level 1: 80 KB
> 
> Bad, 2.6.21-rc5 is running
> sendsize.20070401000504.debug:sendsize[18465]: time 167.371: getting size via gnutar for /usr/music level 0
> sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music level 0: 0.398
> sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music level 0: 2466050 KB
> sendsize.20070401000504.debug:sendsize[18465]: time 167.773: getting size via gnutar for /usr/music level 1
> sendsize.20070401000504.debug:sendsize[18465]: estimate time for /usr/music level 1: 0.049
> sendsize.20070401000504.debug:sendsize[18465]: estimate size for /usr/music level 1: 2448290 KB
> 
> Yesterdays run, dated 20070331000507 were correct as that directory 
> hasn't been write accessed in a couple of months.
> 
> Today's, dated 20070401000504, shows totally bogus figures for exactly 
> the same data.

'totally bogus figures' needs to be analyzed further. What system call 
or library calls returns incorrect data?

> This effect I have isolated down to something in the 31 patches from 
> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in 
> setting up the bisect to find it.  If indeed its a kernel problem.
> 
> This same effect has been present in any and every 2.6.21.* release.

maybe it's some sort of timestamp problem, on the FS level?

	Ingo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-01  5:00 plain 2.6.21-rc5 (1) vs amanda (0) Gene Heskett
  2007-04-01  6:51 ` Ingo Molnar
@ 2007-04-01  7:33 ` Ray Lee
  2007-04-01 15:41   ` Gene Heskett
  1 sibling, 1 reply; 22+ messages in thread
From: Ray Lee @ 2007-04-01  7:33 UTC (permalink / raw)
  To: Gene Heskett; +Cc: Ingo Molnar, amanda-hackers, linux-kernel, amanda-users

On 3/31/07, Gene Heskett <gene.heskett@verizon.net> wrote:
> This effect I have isolated down to something in the 31 patches from
> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
> setting up the bisect to find it.  If indeed its a kernel problem.

First, set up a *small* test case, for your own sanity as well as
ours. (Set up a new backup job that does just part of your home
directory, for example. No, even better, just one file.) Then verify
that the small test case also fails the same was that you noticed your
big one does between 2.6.20.3 and 2.6.20.4.

Then, download everything in http://madrabbit.org/~ray/2.6.20.4 . That
has all the patches that Greg has in git, but your git is ancient so
let's just use the patches, hmm? It also has a control file (called
'series') that lists the order they should be applied in. Save
everything to the root of your 2.6.20.3 source tree. It'll be messy,
but it'll make things easier.

Once you have that, then go and apply the first half of the patches. (As in:
   head -n 16 series | xargs -n 1 patch -p1
at the base of the tree.

Compile and install that kernel, run your test case to see if the
problem is there. If it *is*, cut it in half again (Revert those 16
patches by adding a -R to the patch command (at the very end), then
redo the above command with an 8 instead of a 16.) If the problem
isn't there, cut the range [16,31] in half, giving you a 24 for the
next trial. Then repeat. Make sense?

Ray

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-01  6:51 ` Ingo Molnar
@ 2007-04-01 14:44   ` Gene Heskett
  0 siblings, 0 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-01 14:44 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, amanda-hackers, amanda-users, Andrew Morton, Adrian Bunk

On Sunday 01 April 2007, Ingo Molnar wrote:
>* Gene Heskett <gene.heskett@verizon.net> wrote:
>> Hi Ingo;
>>
>> Running 2.6.21-rc5 tonight.
>>
>> It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in
>> its version string) amanda is still a loser. [...]
>
>here 'is a loser' means: "tries to back up way too much stuff instead of
>doing a nice incremental backup like it does on 2.6.20.4", correct?

Yes, and as an additional clue, 2.6.20.4-rc1 does this, the later 2.6.20.4 
does not, so we have narrowed it down to one or more of the 31 patches in 
that gap.

>since it appears to be caused by a kernel change, this is a serious
>regression in v2.6.21-to-be.

Yes, that's why I'm fussing now, hopefully before this gets into the field 
as a final version.

>> Good, 2.6.20.4 was running
>> sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting
>> size via gnutar for /usr/music level 0
>> sendsize.20070331000507.debug:sendsize[762]: estimate time for
>> /usr/music level 0: 1.239 sendsize.20070331000507.debug:sendsize[762]:
>> estimate size for /usr/music level 0: 2466050 KB
>> sendsize.20070331000507.debug:sendsize[762]: time 249.605: getting
>> size via gnutar for /usr/music level 1
>> sendsize.20070331000507.debug:sendsize[762]: estimate time for
>> /usr/music level 1: 0.027 sendsize.20070331000507.debug:sendsize[762]:
>> estimate size for /usr/music level 1: 80 KB
>>
>> Bad, 2.6.21-rc5 is running
>> sendsize.20070401000504.debug:sendsize[18465]: time 167.371: getting
>> size via gnutar for /usr/music level 0
>> sendsize.20070401000504.debug:sendsize[18465]: estimate time for
>> /usr/music level 0: 0.398
>> sendsize.20070401000504.debug:sendsize[18465]: estimate size for
>> /usr/music level 0: 2466050 KB
>> sendsize.20070401000504.debug:sendsize[18465]: time 167.773: getting
>> size via gnutar for /usr/music level 1
>> sendsize.20070401000504.debug:sendsize[18465]: estimate time for
>> /usr/music level 1: 0.049
>> sendsize.20070401000504.debug:sendsize[18465]: estimate size for
>> /usr/music level 1: 2448290 KB
>>
>> Yesterdays run, dated 20070331000507 were correct as that directory
>> hasn't been write accessed in a couple of months.
>>
>> Today's, dated 20070401000504, shows totally bogus figures for exactly
>> the same data.
>
>'totally bogus figures' needs to be analyzed further. What system call
>or library calls returns incorrect data?

Tar is used with the output sent to /dev/null, to obtain those numbers 
since the last $level figures and these are then assigned to $level + 1.  
Each disklist entry gets scanned twice during the estimate phase, once 
for a level 0 reference, and once for a "since $timestamp" value.  I'm 
not sure if the timestamp in the /etc/amandates file is used, or the 
timestamp on the indice file amandates names is used. Amanda then decides 
what to do next in an attempt to balance the tape usage run to run, and 
not let a needed level 0 ever get more than 1 run behind if amanda can 
help it.  It will drop incrementals to meet that goal if it has to with 
the current order I have setup in my amanda.conf.

>> This effect I have isolated down to something in the 31 patches from
>> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
>> setting up the bisect to find it.  If indeed its a kernel problem.

And I miss-quoted the above, its the 31 patches between 2.6.20.3 and 
2.6.20.4-rc1.  Then for some reason I don't grok, 2.6.20.4 is good again.

>> This same effect has been present in any and every 2.6.21.* release.
>
>maybe it's some sort of timestamp problem, on the FS level?
>
>	Ingo

I wasn't aware of a 'timestamp' problem on the FS level ever being 
discussed at any length here on lkml.  As far as my checking, I'm limited 
to what "ls -lc?" tells me, and those figures seem to be sane.

Is there additional data present now that could screw up tar, and do it 
without being obvious to ls?  I don't know. :-\

-- 
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)
We have only two things to worry about:  That things will never get
back to normal, and that they already have.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-01  7:33 ` Ray Lee
@ 2007-04-01 15:41   ` Gene Heskett
  2007-04-02  4:20     ` Gene Heskett
  0 siblings, 1 reply; 22+ messages in thread
From: Gene Heskett @ 2007-04-01 15:41 UTC (permalink / raw)
  To: linux-kernel, ray-gmail; +Cc: Ingo Molnar, amanda-hackers, amanda-users

On Sunday 01 April 2007, Ray Lee wrote:
>On 3/31/07, Gene Heskett <gene.heskett@verizon.net> wrote:
>> This effect I have isolated down to something in the 31 patches from
>> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance in
>> setting up the bisect to find it.  If indeed its a kernel problem.
>
>First, set up a *small* test case, for your own sanity as well as
>ours. (Set up a new backup job that does just part of your home
>directory, for example. No, even better, just one file.) Then verify
>that the small test case also fails the same was that you noticed your
>big one does between 2.6.20.3 and 2.6.20.4.

That will require I setup a vtape someplace else on the system.
Later, I find the vtapes locations etc are hardcoded into the amanda 
executables, so I'm going to have to rebuild and reinstall amanda after 
copying my regular config driver to a backup version.  Not terribly 
difficult, but I will have to shut down the user amanda's crontab entry 
till we are done with the testing.  This is all part of amanda's security 
model.

Ok, got that done. All logs and such will be to a different location so as 
not to disturb the normal backup once it has been resumed.  The disklist 
has been stripped down to /home.  I guess its time to reboot and test 
run.  I'll reply to this message's thread with the results.

>Then, download everything in http://madrabbit.org/~ray/2.6.20.4 . That
>has all the patches that Greg has in git, but your git is ancient so
>let's just use the patches, hmm?

My git & quilt is now the latest from the FC6 repos.

>It also has a control file (called 
>'series') that lists the order they should be applied in. Save
>everything to the root of your 2.6.20.3 source tree. It'll be messy,
>but it'll make things easier.
>
>Once you have that, then go and apply the first half of the patches. (As
> in: head -n 16 series | xargs -n 1 patch -p1
>at the base of the tree.
>
>Compile and install that kernel, run your test case to see if the
>problem is there. If it *is*, cut it in half again (Revert those 16
>patches by adding a -R to the patch command (at the very end), then
>redo the above command with an 8 instead of a 16.) If the problem
>isn't there, cut the range [16,31] in half, giving you a 24 for the
>next trial. Then repeat. Make sense?
>
>Ray



-- 
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)
Beer -- it's not just for breakfast anymore.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-01 15:41   ` Gene Heskett
@ 2007-04-02  4:20     ` Gene Heskett
  2007-04-02  4:31       ` Dave Dillow
  0 siblings, 1 reply; 22+ messages in thread
From: Gene Heskett @ 2007-04-02  4:20 UTC (permalink / raw)
  To: linux-kernel; +Cc: ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Sunday 01 April 2007, Gene Heskett wrote:
>On Sunday 01 April 2007, Ray Lee wrote:
>>On 3/31/07, Gene Heskett <gene.heskett@verizon.net> wrote:
>>> This effect I have isolated down to something in the 31 patches from
>>> 2.6.20.4 to 2.6.20.5-rc1, but I'm going to need additional guidance
>>> in setting up the bisect to find it.  If indeed its a kernel problem.
>>
>>First, set up a *small* test case, for your own sanity as well as
>>ours. (Set up a new backup job that does just part of your home
>>directory, for example. No, even better, just one file.) Then verify
>>that the small test case also fails the same was that you noticed your
>>big one does between 2.6.20.3 and 2.6.20.4.
>
>That will require I setup a vtape someplace else on the system.
>Later, I find the vtapes locations etc are hardcoded into the amanda
>executables, so I'm going to have to rebuild and reinstall amanda after
>copying my regular config driver to a backup version.  Not terribly
>difficult, but I will have to shut down the user amanda's crontab entry
>till we are done with the testing.  This is all part of amanda's
> security model.
>
>Ok, got that done. All logs and such will be to a different location so
> as not to disturb the normal backup once it has been resumed.  The
> disklist has been stripped down to /home.  I guess its time to reboot
> and test run.  I'll reply to this message's thread with the results.
>
>>Then, download everything in http://madrabbit.org/~ray/2.6.20.4 . That
>>has all the patches that Greg has in git, but your git is ancient so
>>let's just use the patches, hmm?
>
>My git & quilt is now the latest from the FC6 repos.
>
>>It also has a control file (called
>>'series') that lists the order they should be applied in. Save
>>everything to the root of your 2.6.20.3 source tree. It'll be messy,
>>but it'll make things easier.
>>
>>Once you have that, then go and apply the first half of the patches.
>> (As in: head -n 16 series | xargs -n 1 patch -p1
>>at the base of the tree.
>>
>>Compile and install that kernel, run your test case to see if the
>>problem is there. If it *is*, cut it in half again (Revert those 16
>>patches by adding a -R to the patch command (at the very end), then
>>redo the above command with an 8 instead of a 16.) If the problem
>>isn't there, cut the range [16,31] in half, giving you a 24 for the
>>next trial. Then repeat. Make sense?
>>
>>Ray

I haven't gotten that far yet.  A gentleman named Dave Dillow has shown me 
how to demo the problem using only tar in a scripting environment, and it 
is repeatable on a per kernel good or bad basis.
So far, the only difference that I'm seeing is in the Device: line of a 
stat . report, that first number of that line changes from good kernel to 
bad kernel.

>From another email I sent Dave an hour or so ago:

For a good kernel, 2.6.20.3-rdsl-0.31:
[root@coyote bad-kernel]# cd /usr/music
[root@coyote music]# stat .
  File: `.'
  Size: 4096            Blocks: 16         IO Block: 4096   directory
Device: fd00h/64768d    Inode: 10354963    Links: 39
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-04-01 21:07:14.000000000 -0400
Modify: 2006-11-12 06:41:00.000000000 -0500
Change: 2007-01-19 13:15:22.000000000 -0500
[root@coyote music]#                                                               

Now rebooted to 2.6.21-rc5:
[root@coyote ~]# cd /usr/music
[root@coyote music]# stat .
  File: `.'
  Size: 4096            Blocks: 16         IO Block: 4096   directory
Device: ee00h/60928d    Inode: 10354963    Links: 39
Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-04-01 21:07:14.000000000 -0400
Modify: 2006-11-12 06:41:00.000000000 -0500
Change: 2007-01-19 13:15:22.000000000 -0500

What is this difference in the Device: line supposed to mean?

And are we 'getting warmer' here?

Thanks.

-- 
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)
i dont even know if it makes sense at all :) This is an experimental patch
for an experimental kernel :))
	-- Ingo Molnar on linux-kernel

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-02  4:20     ` Gene Heskett
@ 2007-04-02  4:31       ` Dave Dillow
  2007-04-04  4:34         ` Dave Dillow
  0 siblings, 1 reply; 22+ messages in thread
From: Dave Dillow @ 2007-04-02  4:31 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
> >From another email I sent Dave an hour or so ago:
> 
> For a good kernel, 2.6.20.3-rdsl-0.31:
> [root@coyote bad-kernel]# cd /usr/music
> [root@coyote music]# stat .
>   File: `.'
>   Size: 4096            Blocks: 16         IO Block: 4096   directory
> Device: fd00h/64768d    Inode: 10354963    Links: 39
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2007-04-01 21:07:14.000000000 -0400
> Modify: 2006-11-12 06:41:00.000000000 -0500
> Change: 2007-01-19 13:15:22.000000000 -0500
> [root@coyote music]#                                                               
> 
> Now rebooted to 2.6.21-rc5:
> [root@coyote ~]# cd /usr/music
> [root@coyote music]# stat .
>   File: `.'
>   Size: 4096            Blocks: 16         IO Block: 4096   directory
> Device: ee00h/60928d    Inode: 10354963    Links: 39
> Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
> Access: 2007-04-01 21:07:14.000000000 -0400
> Modify: 2006-11-12 06:41:00.000000000 -0500
> Change: 2007-01-19 13:15:22.000000000 -0500
> 
> What is this difference in the Device: line supposed to mean?
> 
> And are we 'getting warmer' here?

For those playing along at home, I believe the issue is that GNU tar
sees a different device number for the directories than what is listed
in the listed-incremental snapshot file, and thinks all of the
directories are new. I've asked Gene to make a few back-to-back runs of
the tar command under the same kernel to see if the subsequent runs
figure out that there's nothing to do, as expected.

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.
Dave

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-02  4:31       ` Dave Dillow
@ 2007-04-04  4:34         ` Dave Dillow
  2007-04-04  8:45           ` Ingo Molnar
  2007-04-09 15:33           ` Gene Heskett
  0 siblings, 2 replies; 22+ messages in thread
From: Dave Dillow @ 2007-04-04  4:34 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
[snipped for brevity]
> > [root@coyote music]# stat .
> > Device: fd00h/64768d    Inode: 10354963    Links: 39

> > Now rebooted to 2.6.21-rc5:
> > Device: ee00h/60928d    Inode: 10354963    Links: 39

> For those playing along at home, I believe the issue is that GNU tar
> sees a different device number for the directories than what is listed
> in the listed-incremental snapshot file, and thinks all of the
> directories are new. I've asked Gene to make a few back-to-back runs of
> the tar command under the same kernel to see if the subsequent runs
> figure out that there's nothing to do, as expected.

Gene has confirmed that GNU tar figures it out as expected.

> 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@osdl.org>
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'm not sure I could argue for that to be reverted, so here's a possible
workaround for Fedora -- completely untested.

Add the following to /etc/modprobe.conf:
options dm_mod major=253

And make a new initrd for the problematic kernel. This assumes that
you're using device mapper as a module.

If you're building it in, then either dm.major=253 or dm_mod.major=253
should work on the kernel command line, but I'm not sure which it is.

Dave

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04  4:34         ` Dave Dillow
@ 2007-04-04  8:45           ` Ingo Molnar
  2007-04-04 17:42             ` Andrew Morton
  2007-04-09 15:33           ` Gene Heskett
  1 sibling, 1 reply; 22+ messages in thread
From: Ingo Molnar @ 2007-04-04  8:45 UTC (permalink / raw)
  To: Dave Dillow, Andrew Morton
  Cc: Gene Heskett, linux-kernel, ray-gmail, amanda-hackers, amanda-users


* Dave Dillow <dave@thedillows.org> 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@osdl.org>
> 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?

	Ingo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04  8:45           ` Ingo Molnar
@ 2007-04-04 17:42             ` Andrew Morton
  2007-04-04 18:17               ` Dave Dillow
  0 siblings, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2007-04-04 17:42 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Dave Dillow, Gene Heskett, linux-kernel, ray-gmail,
	amanda-hackers, amanda-users

On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <mingo@elte.hu> wrote:

> 
> * Dave Dillow <dave@thedillows.org> 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@osdl.org>
> > 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.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04 17:42             ` Andrew Morton
@ 2007-04-04 18:17               ` Dave Dillow
  2007-04-04 20:29                 ` Andrew Morton
  0 siblings, 1 reply; 22+ messages in thread
From: Dave Dillow @ 2007-04-04 18:17 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, Gene Heskett, linux-kernel, ray-gmail,
	amanda-hackers, amanda-users

On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
> On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> 
> > 
> > * Dave Dillow <dave@thedillows.org> 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@osdl.org>
> > > 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@thedillows.org>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04 18:17               ` Dave Dillow
@ 2007-04-04 20:29                 ` Andrew Morton
  2007-04-04 21:55                   ` Dave Dillow
  0 siblings, 1 reply; 22+ messages in thread
From: Andrew Morton @ 2007-04-04 20:29 UTC (permalink / raw)
  To: Dave Dillow
  Cc: Ingo Molnar, Gene Heskett, linux-kernel, ray-gmail,
	amanda-hackers, amanda-users

On Wed, 04 Apr 2007 14:17:13 -0400
Dave Dillow <dave@thedillows.org> wrote:

> On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
> > On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > > 
> > > * Dave Dillow <dave@thedillows.org> 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@osdl.org>
> > > > 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?

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.


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04 20:29                 ` Andrew Morton
@ 2007-04-04 21:55                   ` Dave Dillow
  2007-04-05  0:49                     ` Gene Heskett
  0 siblings, 1 reply; 22+ messages in thread
From: Dave Dillow @ 2007-04-04 21:55 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Ingo Molnar, Gene Heskett, linux-kernel, ray-gmail,
	amanda-hackers, amanda-users

On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
> On Wed, 04 Apr 2007 14:17:13 -0400
> Dave Dillow <dave@thedillows.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.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04 21:55                   ` Dave Dillow
@ 2007-04-05  0:49                     ` Gene Heskett
  0 siblings, 0 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-05  0:49 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Dillow, Andrew Morton, Ingo Molnar, ray-gmail,
	amanda-hackers, amanda-users

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@thedillows.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.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-04  4:34         ` Dave Dillow
  2007-04-04  8:45           ` Ingo Molnar
@ 2007-04-09 15:33           ` Gene Heskett
  2007-04-09 15:59             ` Dave Dillow
  2007-04-09 16:00             ` Ingo Molnar
  1 sibling, 2 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-09 15:33 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Dillow, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Wednesday 04 April 2007, Dave Dillow wrote:
>On Mon, 2007-04-02 at 00:31 -0400, Dave Dillow wrote:
>> On Mon, 2007-04-02 at 00:20 -0400, Gene Heskett wrote:
>
>[snipped for brevity]
>
>> > [root@coyote music]# stat .
>> > Device: fd00h/64768d    Inode: 10354963    Links: 39
>> >
>> > Now rebooted to 2.6.21-rc5:
>> > Device: ee00h/60928d    Inode: 10354963    Links: 39
>>
>> For those playing along at home, I believe the issue is that GNU tar
>> sees a different device number for the directories than what is listed
>> in the listed-incremental snapshot file, and thinks all of the
>> directories are new. I've asked Gene to make a few back-to-back runs
>> of the tar command under the same kernel to see if the subsequent runs
>> figure out that there's nothing to do, as expected.
>
>Gene has confirmed that GNU tar figures it out as expected.
>
>> 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@osdl.org>
>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'm not sure I could argue for that to be reverted, so here's a possible
>workaround for Fedora -- completely untested.
>
>Add the following to /etc/modprobe.conf:
>options dm_mod major=253

This does not work.

>And make a new initrd for the problematic kernel. This assumes that
>you're using device mapper as a module.
>
>If you're building it in, then either dm.major=253 or dm_mod.major=253
>should work on the kernel command line, but I'm not sure which it is.

I'll try this, I just put both in the kernel command line for 2.6.21-rc6, 
except I set it for the 238 it was at before the patch was reverted.  I'd 
put the patch back in myself, but my searching of the lkml corpus here 
hasn't turned it up.

>Dave



-- 
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)
Do not drink coffee in early A.M.  It will keep you awake until noon.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 15:33           ` Gene Heskett
@ 2007-04-09 15:59             ` Dave Dillow
  2007-04-09 16:12               ` Gene Heskett
  2007-04-09 16:30               ` Gene Heskett
  2007-04-09 16:00             ` Ingo Molnar
  1 sibling, 2 replies; 22+ messages in thread
From: Dave Dillow @ 2007-04-09 15:59 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Mon, 2007-04-09 at 11:33 -0400, Gene Heskett wrote:
> >I'm not sure I could argue for that to be reverted, so here's a possible
> >workaround for Fedora -- completely untested.
> >
> >Add the following to /etc/modprobe.conf:
> >options dm_mod major=253
> 
> This does not work.

Hmm, it worked for me when I tested it this weekend. I did use 'dm-mod'
instead of 'dm_mod'.

This was using it on FC6, and LVM isn't loaded until after the initrd
finishes, as I don't use LVM at all. Everything was compiled as modules.

I cannot vouch for it working in the initrd, as I don't have a machine
that uses LVM for the root.

-- 
Dave Dillow <dave@thedillows.org>


^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 15:33           ` Gene Heskett
  2007-04-09 15:59             ` Dave Dillow
@ 2007-04-09 16:00             ` Ingo Molnar
  2007-04-09 17:05               ` Gene Heskett
  1 sibling, 1 reply; 22+ messages in thread
From: Ingo Molnar @ 2007-04-09 16:00 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, Dave Dillow, ray-gmail, amanda-hackers, amanda-users


* Gene Heskett <gene.heskett@gmail.com> wrote:

> I'll try this, I just put both in the kernel command line for 
> 2.6.21-rc6, except I set it for the 238 it was at before the patch was 
> reverted.  I'd put the patch back in myself, but my searching of the 
> lkml corpus here hasn't turned it up.

Andrew has already sent a revert patch to Linus and it's in -rc6. The 
commit is below.

	Ingo

------------>
commit 2363cc0264c42636e9e7622f78dde5c2f66beb8e
Author: Andrew Morton <akpm@linux-foundation.org>
Date:   Wed Apr 4 19:08:22 2007 -0700

    [PATCH] remove protection of LANANA-reserved majors
    
    Revert all this.  It can cause device-mapper to receive a different major from
    earlier kernels and it turns out that the Amanda backup program (via GNU tar,
    apparently) checks major numbers on files when performing incremental backups.
    
    Which is a bit broken of Amanda (or tar), but this feature isn't important
    enough to justify the churn.
    
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

diff --git a/block/genhd.c b/block/genhd.c
index 050a1f0..441432a 100644
--- a/block/genhd.c
+++ b/block/genhd.c
@@ -62,8 +62,6 @@ int register_blkdev(unsigned int major, const char *name)
 	/* temporary */
 	if (major == 0) {
 		for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
-			if (is_lanana_major(index))
-				continue;
 			if (major_names[index] == NULL)
 				break;
 		}
diff --git a/drivers/base/core.c b/drivers/base/core.c
index ad0f4a2..d7fcf82 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -28,20 +28,6 @@ int (*platform_notify)(struct device * dev) = NULL;
 int (*platform_notify_remove)(struct device * dev) = NULL;
 
 /*
- * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
- */
-bool is_lanana_major(unsigned int major)
-{
-	if (major >= 60 && major <= 63)
-		return 1;
-	if (major >= 120 && major <= 127)
-		return 1;
-	if (major >= 240 && major <= 254)
-		return 1;
-	return 0;
-}
-
-/*
  * sysfs bindings for devices.
  */
 
diff --git a/fs/char_dev.c b/fs/char_dev.c
index 78ced72..164a45c 100644
--- a/fs/char_dev.c
+++ b/fs/char_dev.c
@@ -109,8 +109,6 @@ __register_chrdev_region(unsigned int major, unsigned int baseminor,
 	/* temporary */
 	if (major == 0) {
 		for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
-			if (is_lanana_major(i))
-				continue;
 			if (chrdevs[i] == NULL)
 				break;
 		}
diff --git a/include/linux/kdev_t.h b/include/linux/kdev_t.h
index 4c2c373..2dacab8 100644
--- a/include/linux/kdev_t.h
+++ b/include/linux/kdev_t.h
@@ -87,8 +87,6 @@ static inline unsigned sysv_minor(u32 dev)
 	return dev & 0x3ffff;
 }
 
-bool is_lanana_major(unsigned int major);
-
 #else /* __KERNEL__ */
 
 /*

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 15:59             ` Dave Dillow
@ 2007-04-09 16:12               ` Gene Heskett
  2007-04-09 16:30               ` Gene Heskett
  1 sibling, 0 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-09 16:12 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Dillow, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Monday 09 April 2007, Dave Dillow wrote:
>On Mon, 2007-04-09 at 11:33 -0400, Gene Heskett wrote:
>> >I'm not sure I could argue for that to be reverted, so here's a
>> > possible workaround for Fedora -- completely untested.
>> >
>> >Add the following to /etc/modprobe.conf:
>> >options dm_mod major=253
>>
>> This does not work.
>
>Hmm, it worked for me when I tested it this weekend. I did use 'dm-mod'
>instead of 'dm_mod'.
>
As I note it says in a make xconfig help snapshot.  I dutifully copied it 
with a copy/paste.  But since I'm mounting / as an LVM I expect that to 
be a little late although I am building it as a module, but the module is 
being autoloaded by the kernel from the initrd.

I had better double-check that line in grub.conf again.  Thanks for the 
hint.

>This was using it on FC6, and LVM isn't loaded until after the initrd
>finishes, as I don't use LVM at all. Everything was compiled as modules.
>
>I cannot vouch for it working in the initrd, as I don't have a machine
>that uses LVM for the root.



-- 
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)
Evil is that which one believes of others.  It is a sin to believe evil
of others, but it is seldom a mistake.
		-- H.L. Mencken

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 15:59             ` Dave Dillow
  2007-04-09 16:12               ` Gene Heskett
@ 2007-04-09 16:30               ` Gene Heskett
  1 sibling, 0 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-09 16:30 UTC (permalink / raw)
  To: linux-kernel
  Cc: Dave Dillow, ray-gmail, Ingo Molnar, amanda-hackers, amanda-users

On Monday 09 April 2007, Dave Dillow wrote:
>On Mon, 2007-04-09 at 11:33 -0400, Gene Heskett wrote:
>> >I'm not sure I could argue for that to be reverted, so here's a
>> > possible workaround for Fedora -- completely untested.
>> >
>> >Add the following to /etc/modprobe.conf:
>> >options dm_mod major=253
>>
>> This does not work.
>
>Hmm, it worked for me when I tested it this weekend. I did use 'dm-mod'
>instead of 'dm_mod'.
>
>This was using it on FC6, and LVM isn't loaded until after the initrd
>finishes, as I don't use LVM at all. Everything was compiled as modules.
>
>I cannot vouch for it working in the initrd, as I don't have a machine
>that uses LVM for the root.

Now rebooted, with this command line to the kernel:
Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb 
dm-mod.major=238 dm.major=238 selinux=0
Unknown boot option `dm-mod.major=238': ignoring
Unknown boot option `dm.major=238': ignoring

So its still at FE00h/65024d.

And I fixed the underscore to a dash in my modprobe.conf, now I'll do 
another mkinitrd & reboot 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)
	Horses are forbidden to eat fire hydrants in Marshalltown, Iowa.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 16:00             ` Ingo Molnar
@ 2007-04-09 17:05               ` Gene Heskett
  2007-04-09 17:50                 ` Ingo Molnar
  0 siblings, 1 reply; 22+ messages in thread
From: Gene Heskett @ 2007-04-09 17:05 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Dave Dillow, ray-gmail, amanda-hackers, amanda-users

On Monday 09 April 2007, Ingo Molnar wrote:
>* Gene Heskett <gene.heskett@gmail.com> wrote:
>> I'll try this, I just put both in the kernel command line for
>> 2.6.21-rc6, except I set it for the 238 it was at before the patch was
>> reverted.  I'd put the patch back in myself, but my searching of the
>> lkml corpus here hasn't turned it up.
>
>Andrew has already sent a revert patch to Linus and it's in -rc6. The
>commit is below.
>
Is this not the patch that reverts it?  I want the patch that put it in, 
because that will be a one time churn and be done with it, hopefully for 
good.  As it is, its going crazy everytime I rebuild the kernel because 
there are other "EXPERIMENTAL" things too, like md and pktcdvd that are 
constantly sirring the pot and changing the device-mappers major, almost 
on a per boot basis, and this is a hell of a lot less tolerable than a 1 
time churn would have been.  Please note that the finger doing the 
pointing here has two ends, one of which is pointed at the one who 
started this fuss, aka me.  OTOH, that patch that apparently went in 
sometime around 2.6.20.4-rc1 and 2.6.21-rc1, while it was a right patch, 
needed a little more advertising as to what effect it might have.  You'll 
recall I had several of you spinning wheels looking for the culprit, 
something that _should_ have been deducible by looking at the changelog.

As far as the churn is concerned someone has I believe started on a script 
that will fix the churn by editing all the device numbers contained in 
the reference files amanda feeds tar for its 'is it new' detection, to 
whatever the current number is, hopefully something I can incorporate 
into my GenesAmandaHelper package as a separate script to be run 10 
minutes ahead of amdump, or even as a sequential execution.

FWIW, contact with the tar folks has not been productive in this, their 
attitude is that if the device number changed, its a new disk, and if its 
not stable, then its a linux problem and linux should fix it.  And 
grudgingly, I have to admit they are righter than we are in this 
particular dogfight.  I have the -rc5 patch here, and if I thought I 
would recognize it properly, I'd slice it out and use it on rc6 + plus, 
until applying it breaks, indicating its been re-applied by you.  I 
would, in the meantime, have a stable system again.


>	Ingo
>
>------------>
>commit 2363cc0264c42636e9e7622f78dde5c2f66beb8e
>Author: Andrew Morton <akpm@linux-foundation.org>
>Date:   Wed Apr 4 19:08:22 2007 -0700
>
>    [PATCH] remove protection of LANANA-reserved majors
>
>    Revert all this.  It can cause device-mapper to receive a different
> major from earlier kernels and it turns out that the Amanda backup
> program (via GNU tar, apparently) checks major numbers on files when
> performing incremental backups.
>
>    Which is a bit broken of Amanda (or tar), but this feature isn't
> important enough to justify the churn.
>
>    Cc: Ingo Molnar <mingo@elte.hu>
>    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
>
>diff --git a/block/genhd.c b/block/genhd.c
>index 050a1f0..441432a 100644
>--- a/block/genhd.c
>+++ b/block/genhd.c
>@@ -62,8 +62,6 @@ int register_blkdev(unsigned int major, const char
> *name) /* temporary */
> 	if (major == 0) {
> 		for (index = ARRAY_SIZE(major_names)-1; index > 0; index--) {
>-			if (is_lanana_major(index))
>-				continue;
> 			if (major_names[index] == NULL)
> 				break;
> 		}
>diff --git a/drivers/base/core.c b/drivers/base/core.c
>index ad0f4a2..d7fcf82 100644
>--- a/drivers/base/core.c
>+++ b/drivers/base/core.c
>@@ -28,20 +28,6 @@ int (*platform_notify)(struct device * dev) = NULL;
> int (*platform_notify_remove)(struct device * dev) = NULL;
>
> /*
>- * Detect the LANANA-assigned LOCAL/EXPERIMENTAL majors
>- */
>-bool is_lanana_major(unsigned int major)
>-{
>-	if (major >= 60 && major <= 63)
>-		return 1;
>-	if (major >= 120 && major <= 127)
>-		return 1;
>-	if (major >= 240 && major <= 254)
>-		return 1;
>-	return 0;
>-}
>-
>-/*
>  * sysfs bindings for devices.
>  */
>
>diff --git a/fs/char_dev.c b/fs/char_dev.c
>index 78ced72..164a45c 100644
>--- a/fs/char_dev.c
>+++ b/fs/char_dev.c
>@@ -109,8 +109,6 @@ __register_chrdev_region(unsigned int major,
> unsigned int baseminor, /* temporary */
> 	if (major == 0) {
> 		for (i = ARRAY_SIZE(chrdevs)-1; i > 0; i--) {
>-			if (is_lanana_major(i))
>-				continue;
> 			if (chrdevs[i] == NULL)
> 				break;
> 		}
>diff --git a/include/linux/kdev_t.h b/include/linux/kdev_t.h
>index 4c2c373..2dacab8 100644
>--- a/include/linux/kdev_t.h
>+++ b/include/linux/kdev_t.h
>@@ -87,8 +87,6 @@ static inline unsigned sysv_minor(u32 dev)
> 	return dev & 0x3ffff;
> }
>
>-bool is_lanana_major(unsigned int major);
>-
> #else /* __KERNEL__ */
>
> /*



-- 
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)
Q:	Why do the police always travel in threes?
A:	One to do the reading, one to do the writing, and the other keeps
	an eye on the two intellectuals.

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 17:05               ` Gene Heskett
@ 2007-04-09 17:50                 ` Ingo Molnar
  2007-04-09 19:58                   ` Gene Heskett
  0 siblings, 1 reply; 22+ messages in thread
From: Ingo Molnar @ 2007-04-09 17:50 UTC (permalink / raw)
  To: Gene Heskett
  Cc: linux-kernel, Dave Dillow, ray-gmail, amanda-hackers, amanda-users


* Gene Heskett <gene.heskett@gmail.com> wrote:

> > Andrew has already sent a revert patch to Linus and it's in -rc6. 
> > The commit is below.
>
> Is this not the patch that reverts it?  I want the patch that put it 
> in, because that will be a one time churn and be done with it, 
> hopefully for good. [...]

any patch can be reverse-applied by doing "patch -R ...".

	Ingo

^ permalink raw reply	[flat|nested] 22+ messages in thread

* Re: plain 2.6.21-rc5 (1) vs amanda (0)
  2007-04-09 17:50                 ` Ingo Molnar
@ 2007-04-09 19:58                   ` Gene Heskett
  0 siblings, 0 replies; 22+ messages in thread
From: Gene Heskett @ 2007-04-09 19:58 UTC (permalink / raw)
  To: linux-kernel
  Cc: Ingo Molnar, Dave Dillow, ray-gmail, amanda-hackers, amanda-users

On Monday 09 April 2007, Ingo Molnar wrote:
>* Gene Heskett <gene.heskett@gmail.com> wrote:
>> > Andrew has already sent a revert patch to Linus and it's in -rc6.
>> > The commit is below.
>>
>> Is this not the patch that reverts it?  I want the patch that put it
>> in, because that will be a one time churn and be done with it,
>> hopefully for good. [...]
>
>any patch can be reverse-applied by doing "patch -R ...".

Duh!, old farts short term memory strikes again.  However I finally do 
have that nailed down to 238 now.  I had a typu in my modprobe.conf  :(

>	Ingo



-- 
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)
	WARNING TO ALL PERSONNEL:

Firings will continue until morale improves.

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2007-04-09 19:58 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-04-01  5:00 plain 2.6.21-rc5 (1) vs amanda (0) Gene Heskett
2007-04-01  6:51 ` Ingo Molnar
2007-04-01 14:44   ` Gene Heskett
2007-04-01  7:33 ` Ray Lee
2007-04-01 15:41   ` Gene Heskett
2007-04-02  4:20     ` Gene Heskett
2007-04-02  4:31       ` Dave Dillow
2007-04-04  4:34         ` Dave Dillow
2007-04-04  8:45           ` Ingo Molnar
2007-04-04 17:42             ` Andrew Morton
2007-04-04 18:17               ` Dave Dillow
2007-04-04 20:29                 ` Andrew Morton
2007-04-04 21:55                   ` Dave Dillow
2007-04-05  0:49                     ` Gene Heskett
2007-04-09 15:33           ` Gene Heskett
2007-04-09 15:59             ` Dave Dillow
2007-04-09 16:12               ` Gene Heskett
2007-04-09 16:30               ` Gene Heskett
2007-04-09 16:00             ` Ingo Molnar
2007-04-09 17:05               ` Gene Heskett
2007-04-09 17:50                 ` Ingo Molnar
2007-04-09 19:58                   ` Gene Heskett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).