Re: plain 2.6.21-rc5 (1) vs amanda (0)
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 <[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)
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
Re: plain 2.6.21-rc5 (1) vs amanda (0)
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)
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 <[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)
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)
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)
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)
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)
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)
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)
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 <[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)
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)
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)
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)
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)
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)
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 <[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/
plain 2.6.21-rc5 (1) vs amanda (0)
Hi Ingo; Running 2.6.21-rc5 tonight. It appears that as of 2.6.21-rc5, (actually anything with a 2.6.21 in its version string) amanda is still a loser. >From an amstatus report as the back up is just getting started, and amanda has completed the estimates: [EMAIL PROTECTED] Daily]# amstatus Daily Using /usr/local/var/amanda/Daily/amdump from Sun Apr 1 00:05:04 EDT 2007 coyote:/GenesAmandaHelper-0.5 1 planner: [dumps way too big, 156684 KB, must skip incremental dumps] coyote:/GenesAmandaHelper-0.6 4 planner: [dumps way too big, 780226 KB, must skip incremental dumps] coyote:/bin 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/boot 13m wait for dumping coyote:/dev 00m wait for dumping coyote:/etc 2 planner: [dumps way too big, 18533 KB, must skip incremental dumps] coyote:/home 0 858m wait for dumping coyote:/lib 1 planner: [dumps way too big, 100080 KB, must skip incremental dumps] coyote:/opt 1 2192m wait for dumping coyote:/root 2 planner: [dumps way too big, 1684448 KB, must skip incremental dumps] coyote:/sbin 10m wait for dumping coyote:/tmp 1 planner: [dumps way too big, 8972 KB, must skip incremental dumps] coyote:/usr/X11R6 1 planner: [dumps way too big, 232 KB, must skip incremental dumps] coyote:/usr/bin 1 planner: [dumps way too big, 26030 KB, must skip incremental dumps] coyote:/usr/dlds 1 planner: [dumps way too big, 93030 KB, must skip incremental dumps] coyote:/usr/dlds-misc 2 155m wait for dumping coyote:/usr/dlds-rpms 1 planner: [dumps way too big, 10 KB, must skip incremental dumps] coyote:/usr/dlds-tgzs 10m wait for dumping coyote:/usr/games 00m wait for dumping coyote:/usr/include 1 85m wait for dumping coyote:/usr/kerberos 1 planner: [dumps way too big, 1360 KB, must skip incremental dumps] coyote:/usr/lib 3 planner: [dumps way too big, 337013 KB, must skip incremental dumps] coyote:/usr/libexec 1 planner: [dumps way too big, 20138 KB, must skip incremental dumps] coyote:/usr/local 1 planner: [dumps way too big, 42374 KB, must skip incremental dumps] coyote:/usr/man 1 planner: [dumps way too big, 710 KB, must skip incremental dumps] coyote:/usr/movies1 7271m dumping 5298m ( 72.87%) (0:12:48) coyote:/usr/music 1 planner: [dumps way too big, 2448290 KB, must skip incremental dumps] coyote:/usr/pix 1 planner: [dumps way too big, 856480 KB, must skip incremental dumps] coyote:/usr/sbin 1 planner: [dumps way too big, 2305 KB, must skip incremental dumps] coyote:/usr/share 2 planner: [dumps way too big, 348843 KB, must skip incremental dumps] coyote:/usr/src 1 planner: [dumps way too big, 2519056 KB, must skip incremental dumps] coyote:/var 3 3774m wait for dumping SUMMARY part real estimated size size partition : 32 estimated : 3242307m flush : 0 0m failed : 2127964m ( 66.10%) wait for dumping: 10 7070m ( 16.71%) dumping to tape : 00m ( 0.00%) dumping : 1 5298m 7271m ( 72.87%) ( 12.52%) dumped : 0 0m 0m ( 0.00%) ( 0.00%) wait for writing: 0 0m 0m ( 0.00%) ( 0.00%) wait to flush : 0 0m 0m (100.00%) ( 0.00%) writing to tape : 0 0m 0m ( 0.00%) ( 0.00%) failed to tape : 0 0m 0m ( 0.00%) ( 0.00%) taped : 0 0m 0m ( 0.00%) ( 0.00%) tape 1: 0 0m 0m ( 0.00%) Dailys-17 8 dumpers idle : not-idle taper idle network free kps: 6800 holding space : 66234m (100.00%) dumper0 busy : 0:00:00 ( 0.00%) 0 dumpers busy : 0:00:00 ( 0.00%) 1 dumper busy : 0:00:00 ( 0.00%) [EMAIL PROTECTED] Daily]# Anything above that's 'way too big' is within a percent or so, regardless of the level, of a full, every byte backup. The number in column 31 above is the backup level that disklist entry is getting right now. As a sample of how it is being messed with, for a single, approximately 2.5GB collection of music I have, are the outputs of the sendsize function for the last 2 runs, yesterdays dated files were obtained running 2.6.20.4 and todays were obtained with 2.6.21-rc5. Good, 2.6.20.4 was running sendsize.20070331000507.debug:sendsize[762]: time 248.361: getting size via gnutar for /usr/music level 0 sendsize.20070331000507.debug:sendsize[762]: estimate time for /usr/music level