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

[Gene Heskett]

On Monday 09 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Monday 09 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>
>Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
>
>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)
>   

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

[Gene Heskett]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>

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 & 0x3;
 }
 
-bool is_lanana_major(unsigned int major);
-
 #else /* __KERNEL__ */
 
 /*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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 <[EMAIL PROTECTED]>

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

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

[Gene Heskett]

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]
>
>> > [EMAIL PROTECTED] music]# stat .
>> > Device: fd00h/64768dInode: 10354963Links: 39
>> >
>> > Now rebooted to 2.6.21-rc5:
>> > Device: ee00h/60928dInode: 10354963Links: 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 <[EMAIL PROTECTED]>
>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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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]

  [EMAIL PROTECTED] music]# stat .
  Device: fd00h/64768dInode: 10354963Links: 39
 
  Now rebooted to 2.6.21-rc5:
  Device: ee00h/60928dInode: 10354963Links: 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 [EMAIL PROTECTED]
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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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 [EMAIL PROTECTED]

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

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

[Ingo Molnar]

* Gene Heskett [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

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  0x3;
 }
 
-bool is_lanana_major(unsigned int major);
-
 #else /* __KERNEL__ */
 
 /*
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Monday 09 April 2007, Ingo Molnar wrote:
* Gene Heskett [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Linus Torvalds [EMAIL PROTECTED]

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  0x3;
 }

-bool is_lanana_major(unsigned int major);
-
 #else /* __KERNEL__ */

 /*



-- 
Cheers, Gene

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

[Ingo Molnar]

* Gene Heskett [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Monday 09 April 2007, Ingo Molnar wrote:
* Gene Heskett [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
> On Wed, 04 Apr 2007 14:17:13 -0400
> Dave Dillow <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Andrew Morton]

On Wed, 04 Apr 2007 14:17:13 -0400
Dave Dillow <[EMAIL PROTECTED]> wrote:

> On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
> > On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > 
> > > 
> > > * Dave Dillow <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > > > 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.

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

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 <[EMAIL PROTECTED]> wrote:
> 
> > 
> > * Dave Dillow <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > > 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 <[EMAIL PROTECTED]>

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

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

[Andrew Morton]

On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * Dave Dillow <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Dave Dillow <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Dave Dillow [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Andrew Morton]

On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:

 
 * Dave Dillow [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
  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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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 [EMAIL PROTECTED] wrote:
 
  
  * Dave Dillow [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
   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 [EMAIL PROTECTED]

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

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

[Andrew Morton]

On Wed, 04 Apr 2007 14:17:13 -0400
Dave Dillow [EMAIL PROTECTED] wrote:

 On Wed, 2007-04-04 at 10:42 -0700, Andrew Morton wrote:
  On Wed, 4 Apr 2007 10:45:30 +0200 Ingo Molnar [EMAIL PROTECTED] wrote:
  
   
   * Dave Dillow [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
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.

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

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

[Dave Dillow]

On Wed, 2007-04-04 at 13:29 -0700, Andrew Morton wrote:
 On Wed, 04 Apr 2007 14:17:13 -0400
 Dave Dillow [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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]
> > [EMAIL PROTECTED] music]# stat .
> > Device: fd00h/64768dInode: 10354963Links: 39

> > Now rebooted to 2.6.21-rc5:
> > Device: ee00h/60928dInode: 10354963Links: 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 <[EMAIL PROTECTED]>
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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]
  [EMAIL PROTECTED] music]# stat .
  Device: fd00h/64768dInode: 10354963Links: 39

  Now rebooted to 2.6.21-rc5:
  Device: ee00h/60928dInode: 10354963Links: 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 [EMAIL PROTECTED]
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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:
> [EMAIL PROTECTED] bad-kernel]# cd /usr/music
> [EMAIL PROTECTED] music]# stat .
>   File: `.'
>   Size: 4096Blocks: 16 IO Block: 4096   directory
> Device: fd00h/64768dInode: 10354963Links: 39
> Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> Access: 2007-04-01 21:07:14.0 -0400
> Modify: 2006-11-12 06:41:00.0 -0500
> Change: 2007-01-19 13:15:22.0 -0500
> [EMAIL PROTECTED] music]# 
>   
> 
> Now rebooted to 2.6.21-rc5:
> [EMAIL PROTECTED] ~]# cd /usr/music
> [EMAIL PROTECTED] music]# stat .
>   File: `.'
>   Size: 4096Blocks: 16 IO Block: 4096   directory
> Device: ee00h/60928dInode: 10354963Links: 39
> Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
> Access: 2007-04-01 21:07:14.0 -0400
> Modify: 2006-11-12 06:41:00.0 -0500
> Change: 2007-01-19 13:15:22.0 -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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Gene Heskett wrote:
>On Sunday 01 April 2007, Ray Lee wrote:
>>On 3/31/07, Gene Heskett <[EMAIL PROTECTED]> 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:
[EMAIL PROTECTED] bad-kernel]# cd /usr/music
[EMAIL PROTECTED] music]# stat .
  File: `.'
  Size: 4096Blocks: 16 IO Block: 4096   directory
Device: fd00h/64768dInode: 10354963Links: 39
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2007-04-01 21:07:14.0 -0400
Modify: 2006-11-12 06:41:00.0 -0500
Change: 2007-01-19 13:15:22.0 -0500
[EMAIL PROTECTED] music]#   


Now rebooted to 2.6.21-rc5:
[EMAIL PROTECTED] ~]# cd /usr/music
[EMAIL PROTECTED] music]# stat .
  File: `.'
  Size: 4096Blocks: 16 IO Block: 4096   directory
Device: ee00h/60928dInode: 10354963Links: 39
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2007-04-01 21:07:14.0 -0400
Modify: 2006-11-12 06:41:00.0 -0500
Change: 2007-01-19 13:15:22.0 -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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Ray Lee wrote:
>On 3/31/07, Gene Heskett <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Ingo Molnar wrote:
>* Gene Heskett <[EMAIL PROTECTED]> 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ray Lee]

On 3/31/07, Gene Heskett <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ray Lee]

On 3/31/07, Gene Heskett [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Ingo Molnar wrote:
* Gene Heskett [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Ray Lee wrote:
On 3/31/07, Gene Heskett [EMAIL PROTECTED] 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.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Gene Heskett]

On Sunday 01 April 2007, Gene Heskett wrote:
On Sunday 01 April 2007, Ray Lee wrote:
On 3/31/07, Gene Heskett [EMAIL PROTECTED] 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:
[EMAIL PROTECTED] bad-kernel]# cd /usr/music
[EMAIL PROTECTED] music]# stat .
  File: `.'
  Size: 4096Blocks: 16 IO Block: 4096   directory
Device: fd00h/64768dInode: 10354963Links: 39
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2007-04-01 21:07:14.0 -0400
Modify: 2006-11-12 06:41:00.0 -0500
Change: 2007-01-19 13:15:22.0 -0500
[EMAIL PROTECTED] music]#   


Now rebooted to 2.6.21-rc5:
[EMAIL PROTECTED] ~]# cd /usr/music
[EMAIL PROTECTED] music]# stat .
  File: `.'
  Size: 4096Blocks: 16 IO Block: 4096   directory
Device: ee00h/60928dInode: 10354963Links: 39
Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
Access: 2007-04-01 21:07:14.0 -0400
Modify: 2006-11-12 06:41:00.0 -0500
Change: 2007-01-19 13:15:22.0 -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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Dave Dillow]

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:
 [EMAIL PROTECTED] bad-kernel]# cd /usr/music
 [EMAIL PROTECTED] music]# stat .
   File: `.'
   Size: 4096Blocks: 16 IO Block: 4096   directory
 Device: fd00h/64768dInode: 10354963Links: 39
 Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
 Access: 2007-04-01 21:07:14.0 -0400
 Modify: 2006-11-12 06:41:00.0 -0500
 Change: 2007-01-19 13:15:22.0 -0500
 [EMAIL PROTECTED] music]# 
   
 
 Now rebooted to 2.6.21-rc5:
 [EMAIL PROTECTED] ~]# cd /usr/music
 [EMAIL PROTECTED] music]# stat .
   File: `.'
   Size: 4096Blocks: 16 IO Block: 4096   directory
 Device: ee00h/60928dInode: 10354963Links: 39
 Access: (0755/drwxr-xr-x)  Uid: (0/root)   Gid: (0/root)
 Access: 2007-04-01 21:07:14.0 -0400
 Modify: 2006-11-12 06:41:00.0 -0500
 Change: 2007-01-19 13:15:22.0 -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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Gene Heskett <[EMAIL PROTECTED]> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

[Ingo Molnar]

* Gene Heskett [EMAIL PROTECTED] 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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/