Re: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Tuesday 13 March 2007, Willy Tarreau wrote:
>On Tue, Mar 13, 2007 at 12:04:42AM -0400, Gene Heskett wrote:
>> On Monday 12 March 2007, Nish Aravamudan wrote:
>> >On 3/12/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
>> >> On Monday 12 March 2007, Douglas McNaught wrote:
>> >> >Patrick Mau <[EMAIL PROTECTED]> writes:
>> >> >> Why not temporarly replace "/bin/tar" with a shell script that
>> >> >> does:
>> >> >>
>> >> >> #!/bin/sh
>> >> >> exec strace -f -o output /bin/real.tar $@
>> >> >
>> >> >You beat me to it. :) I've done that before; it's a great
>> >> > suggestion.
>> >> >
>> >> >Except that if you expect 'tar' to be invoked multiple times in a
>> >> > run, you should probably use 'output.$$' for the output filename
>> >> > so things don't get clobbered.
>> >> >
>> >> >-Doug
>> >>
>> >> In my case, Doug, it will get invoked 64 times, amanda does a dummy
>> >> run to get an estimate, calculates what to do based on that output
>> >> which is 32 runs, 1 per disklist entry and I have 32, and then
>> >> reruns tar with the appropriate level options against each
>> >> individual disklist entry.
>> >>
>> >> But I'm puzzled a bit, what does the double $$ do?, or it buried
>> >> someplace in the bash manpage? Its not something I've stumbled
>> >> over yet.
>> >
>> >buried indeed:
>> >
>> >"Special Parameters:
>> > ...
>> > $ Expands to the process ID of the shell. In a ()
>> > subshell, it expands to the process ID of the current shell,
>> > not the sub?$B!> shell.
>> >"
>>
>> Well, that's clear enough, but what of the double $$ case? Would this
>> them make a PID unique to each invocation untill it finally wraps a 16
>> bit value, or will the kernel re-use them because they won't all be
>> running simultainiously, but limited by the number of unique 'spindle'
>> numbers on the system, this to prevent as best as it can, the
>> thrashing of a drive by having tar working on 2 separate (or more)
>> partitions at the same time. In my case 2 are possible, as /var is on
>> a separate drive.
>
>Yes there a risk of wrapping, but it is very small. You can add the
> command line arguments to the file name if you want, like this :
>
>#!/bin/sh
>exec strace -f -o "output.$$.${*//\//_}" /bin/real.tar $@
>
>It will name the output file "output..", replacing slashes
> with underscores. This is very dirty but can help.
>
Excellent Willy, thanks.
>Cheers,
>Willy
--
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)
Whatever doesn't succeed in two months and a half in California will
never succeed.
-- Rev. Henry Durant, founder of the University of California
-
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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Tue, Mar 13, 2007 at 12:04:42AM -0400, Gene Heskett wrote:
> On Monday 12 March 2007, Nish Aravamudan wrote:
> >On 3/12/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
> >> On Monday 12 March 2007, Douglas McNaught wrote:
> >> >Patrick Mau <[EMAIL PROTECTED]> writes:
> >> >> Why not temporarly replace "/bin/tar" with a shell script that
> >> >> does:
> >> >>
> >> >> #!/bin/sh
> >> >> exec strace -f -o output /bin/real.tar $@
> >> >
> >> >You beat me to it. :) I've done that before; it's a great
> >> > suggestion.
> >> >
> >> >Except that if you expect 'tar' to be invoked multiple times in a
> >> > run, you should probably use 'output.$$' for the output filename so
> >> > things don't get clobbered.
> >> >
> >> >-Doug
> >>
> >> In my case, Doug, it will get invoked 64 times, amanda does a dummy
> >> run to get an estimate, calculates what to do based on that output
> >> which is 32 runs, 1 per disklist entry and I have 32, and then reruns
> >> tar with the appropriate level options against each individual
> >> disklist entry.
> >>
> >> But I'm puzzled a bit, what does the double $$ do?, or it buried
> >> someplace in the bash manpage? Its not something I've stumbled over
> >> yet.
> >
> >buried indeed:
> >
> >"Special Parameters:
> > ...
> > $ Expands to the process ID of the shell. In a ()
> > subshell, it expands to the process ID of the current shell, not
> > the sub?$B!> shell.
> >"
>
> Well, that's clear enough, but what of the double $$ case? Would this
> them make a PID unique to each invocation untill it finally wraps a 16
> bit value, or will the kernel re-use them because they won't all be
> running simultainiously, but limited by the number of unique 'spindle'
> numbers on the system, this to prevent as best as it can, the thrashing
> of a drive by having tar working on 2 separate (or more) partitions at
> the same time. In my case 2 are possible, as /var is on a separate
> drive.
Yes there a risk of wrapping, but it is very small. You can add the command
line arguments to the file name if you want, like this :
#!/bin/sh
exec strace -f -o "output.$$.${*//\//_}" /bin/real.tar $@
It will name the output file "output..", replacing slashes with
underscores. This is very dirty but can help.
Cheers,
Willy
-
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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Monday 12 March 2007, Nish Aravamudan wrote: >On 3/12/07, Gene Heskett <[EMAIL PROTECTED]> wrote: >> On Monday 12 March 2007, Douglas McNaught wrote: >> >Patrick Mau <[EMAIL PROTECTED]> writes: >> >> Why not temporarly replace "/bin/tar" with a shell script that >> >> does: >> >> >> >> #!/bin/sh >> >> exec strace -f -o output /bin/real.tar $@ >> > >> >You beat me to it. :) I've done that before; it's a great >> > suggestion. >> > >> >Except that if you expect 'tar' to be invoked multiple times in a >> > run, you should probably use 'output.$$' for the output filename so >> > things don't get clobbered. >> > >> >-Doug >> >> In my case, Doug, it will get invoked 64 times, amanda does a dummy >> run to get an estimate, calculates what to do based on that output >> which is 32 runs, 1 per disklist entry and I have 32, and then reruns >> tar with the appropriate level options against each individual >> disklist entry. >> >> But I'm puzzled a bit, what does the double $$ do?, or it buried >> someplace in the bash manpage? Its not something I've stumbled over >> yet. > >buried indeed: > >"Special Parameters: > ... > $ Expands to the process ID of the shell. In a () > subshell, it expands to the process ID of the current shell, not > the sub‐ shell. >" Well, that's clear enough, but what of the double $$ case? Would this them make a PID unique to each invocation untill it finally wraps a 16 bit value, or will the kernel re-use them because they won't all be running simultainiously, but limited by the number of unique 'spindle' numbers on the system, this to prevent as best as it can, the thrashing of a drive by having tar working on 2 separate (or more) partitions at the same time. In my case 2 are possible, as /var is on a separate drive. >Thanks, >Nish -- 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) "Say yur prayers, yuh flea-pickin' varmint!" -- Yosemite Sam - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On 3/12/07, Gene Heskett <[EMAIL PROTECTED]> wrote: On Monday 12 March 2007, Douglas McNaught wrote: >Patrick Mau <[EMAIL PROTECTED]> writes: >> Why not temporarly replace "/bin/tar" with a shell script that does: >> >> #!/bin/sh >> exec strace -f -o output /bin/real.tar $@ > >You beat me to it. :) I've done that before; it's a great suggestion. > >Except that if you expect 'tar' to be invoked multiple times in a run, >you should probably use 'output.$$' for the output filename so things >don't get clobbered. > >-Doug In my case, Doug, it will get invoked 64 times, amanda does a dummy run to get an estimate, calculates what to do based on that output which is 32 runs, 1 per disklist entry and I have 32, and then reruns tar with the appropriate level options against each individual disklist entry. But I'm puzzled a bit, what does the double $$ do?, or it buried someplace in the bash manpage? Its not something I've stumbled over yet. buried indeed: "Special Parameters: ... $ Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the current shell, not the sub‐ shell. " Thanks, Nish - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Monday 12 March 2007, Douglas McNaught wrote: >Patrick Mau <[EMAIL PROTECTED]> writes: >> Why not temporarly replace "/bin/tar" with a shell script that does: >> >> #!/bin/sh >> exec strace -f -o output /bin/real.tar $@ > >You beat me to it. :) I've done that before; it's a great suggestion. > >Except that if you expect 'tar' to be invoked multiple times in a run, >you should probably use 'output.$$' for the output filename so things >don't get clobbered. > >-Doug In my case, Doug, it will get invoked 64 times, amanda does a dummy run to get an estimate, calculates what to do based on that output which is 32 runs, 1 per disklist entry and I have 32, and then reruns tar with the appropriate level options against each individual disklist entry. But I'm puzzled a bit, what does the double $$ do?, or it buried someplace in the bash manpage? Its not something I've stumbled over yet. -- 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) rugged, adj.: Too heavy to lift. - 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/
Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
Patrick Mau <[EMAIL PROTECTED]> writes: > Why not temporarly replace "/bin/tar" with a shell script that does: > > #!/bin/sh > exec strace -f -o output /bin/real.tar $@ You beat me to it. :) I've done that before; it's a great suggestion. Except that if you expect 'tar' to be invoked multiple times in a run, you should probably use 'output.$$' for the output filename so things don't get clobbered. -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Patrick Mau wrote: >On Mon, Mar 12, 2007 at 03:43:09PM -0400, Douglas McNaught wrote: >> Gene Heskett <[EMAIL PROTECTED]> writes: >> > On Monday 12 March 2007, Douglas McNaught wrote: >> >>Gene Heskett <[EMAIL PROTECTED]> writes: >> >>> I'd considered it, but with 32 dle entries, the whole strace >> >>> output would be terrabytes & I don't have THAT much disk. Not to >> >>> mention it traces only the parent process, so tar would be merrily >> >>> marching along to its own drummer and not traced I'm afraid. >> >> >> >>$ strace -ff >> >> >> >>-Doug >> > >> > Someone else suggested the single -f, and I tried that, but even >> > with the shell history set for 100,000 lines, i can't get back to >> > the start, and I think its mucking with the shell arguments >> > numbering as what I can see is about 5 reads through /etc/services >> > accompanied by endless complaints of -EBADFD, the the logfile it >> > generates says the port it was given was rejected when amcheck was >> > run, here is that snip: >> >> I'd do 'strace -ff -o /tmp/amanda-strace ', which will give >> you a set of files in /tmp, one for each PID created by fork(). Then >> find the one that has the 'tar' invocation you're looking for. > >Hi, > >I hope you don't mind me jumping in ... > >Why not temporarly replace "/bin/tar" with a shell script that does: > >#!/bin/sh >exec strace -f -o output /bin/real.tar $@ > >That should be working, shouldn't it ? > >Cheers, >Patrick It should I'd think, for those instances where these scripts are run by hand and therefore have a shell to output to. I'll give that a try when I get my script problem resolved, its a basic diff in the operation of real tapes and vtapes I need to get right for both scenarios. Good Idea(TM), 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) "Ignorance is the soil in which belief in miracles grows." -- Robert G. Ingersoll - 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: RSDL for 2.6.21-rc3- 0.29
On Mon, Mar 12, 2007 at 03:43:09PM -0400, Douglas McNaught wrote: > Gene Heskett <[EMAIL PROTECTED]> writes: > > > On Monday 12 March 2007, Douglas McNaught wrote: > >>Gene Heskett <[EMAIL PROTECTED]> writes: > >>> I'd considered it, but with 32 dle entries, the whole strace output > >>> would be terrabytes & I don't have THAT much disk. Not to mention it > >>> traces only the parent process, so tar would be merrily marching along > >>> to its own drummer and not traced I'm afraid. > >> > >>$ strace -ff > >> > >>-Doug > > > > Someone else suggested the single -f, and I tried that, but even with the > > shell history set for 100,000 lines, i can't get back to the start, and I > > think its mucking with the shell arguments numbering as what I can see is > > about 5 reads through /etc/services accompanied by endless complaints > > of -EBADFD, the the logfile it generates says the port it was given was > > rejected when amcheck was run, here is that snip: > > I'd do 'strace -ff -o /tmp/amanda-strace ', which will give > you a set of files in /tmp, one for each PID created by fork(). Then > find the one that has the 'tar' invocation you're looking for. Hi, I hope you don't mind me jumping in ... Why not temporarly replace "/bin/tar" with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ That should be working, shouldn't it ? Cheers, Patrick - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett <[EMAIL PROTECTED]> writes: > On Monday 12 March 2007, Douglas McNaught wrote: >>Gene Heskett <[EMAIL PROTECTED]> writes: >>> I'd considered it, but with 32 dle entries, the whole strace output >>> would be terrabytes & I don't have THAT much disk. Not to mention it >>> traces only the parent process, so tar would be merrily marching along >>> to its own drummer and not traced I'm afraid. >> >>$ strace -ff >> >>-Doug > > Someone else suggested the single -f, and I tried that, but even with the > shell history set for 100,000 lines, i can't get back to the start, and I > think its mucking with the shell arguments numbering as what I can see is > about 5 reads through /etc/services accompanied by endless complaints > of -EBADFD, the the logfile it generates says the port it was given was > rejected when amcheck was run, here is that snip: I'd do 'strace -ff -o /tmp/amanda-strace ', which will give you a set of files in /tmp, one for each PID created by fork(). Then find the one that has the 'tar' invocation you're looking for. -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On 3/12/07, Gene Heskett <[EMAIL PROTECTED]> wrote: On Monday 12 March 2007, Douglas McNaught wrote: >Gene Heskett <[EMAIL PROTECTED]> writes: >> I'd considered it, but with 32 dle entries, the whole strace output >> would be terrabytes & I don't have THAT much disk. Not to mention it >> traces only the parent process, so tar would be merrily marching along >> to its own drummer and not traced I'm afraid. > >$ strace -ff > >-Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: Can we start a new thread for this amanda issue? It does not seem to have anything to do with Con's scheduler... Lee - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Douglas McNaught wrote: >Gene Heskett <[EMAIL PROTECTED]> writes: >> I'd considered it, but with 32 dle entries, the whole strace output >> would be terrabytes & I don't have THAT much disk. Not to mention it >> traces only the parent process, so tar would be merrily marching along >> to its own drummer and not traced I'm afraid. > >$ strace -ff > >-Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: running /usr/local/sbin//amcheck Daily Amanda Tape Server Host Check - Holding disk /dumps: 72597 MB disk space available, using 72097 MB slot 5: read label `Dailys-5', date `20070223002502' NOTE: skipping tape-writable test Tape Dailys-5 label ok Server check took 4.556 seconds Amanda Backup Client Hosts Check WARNING: coyote: selfcheck request failed: unable to bind to a reserved port (got port 32789) Client check: 1 host checked in 34.733 seconds, 1 problem found (brought to you by Amanda 2.5.1p3-20070222) --eofsnip The script quit by request shortly after as I didn't want it to further dirty the amanda database system. -- 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) Safety Third. - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett <[EMAIL PROTECTED]> writes: > I'd considered it, but with 32 dle entries, the whole strace output would > be terrabytes & I don't have THAT much disk. Not to mention it traces > only the parent process, so tar would be merrily marching along to its > own drummer and not traced I'm afraid. $ strace -ff -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Douglas McNaught wrote: >Gene Heskett <[EMAIL PROTECTED]> writes: >> If, and I have previously, I revert to a 2.6.20-ck1 patching, this >> does not occur. So my contention is that someplace in this recent >> progression from 2.6.20 to 2.6.21-rc3, there is a patch which acts to >> change how c-time is being reported to tar. Or there is a spillage >> into c-times when tar does its estimate scans where the output goes to >> /dev/null. Or possibly even this version of tar is doing it >> differently. I just looked up how to get the c-times out of ls, and >> they, as far as ls is concerned, look sane. But tars actions while >> running a 2.6.21-rcX kernel certainly are not. I do have a plain -rc2 >> I can try, so that will be the next test. If that also fails in this >> manner, I'll build a later 2.6.20-2 or whatever to verify that it >> doesn't so suffer. > >You may find 'strace' useful to track down this sort of thing (though >the output can be voluminous). > >-Doug I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes & I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. -- 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'm definitely not in Omaha! - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett <[EMAIL PROTECTED]> writes: > If, and I have previously, I revert to a 2.6.20-ck1 patching, this does > not occur. So my contention is that someplace in this recent progression > from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how > c-time is being reported to tar. Or there is a spillage into c-times > when tar does its estimate scans where the output goes to /dev/null. > Or possibly even this version of tar is doing it differently. I just > looked up how to get the c-times out of ls, and they, as far as ls is > concerned, look sane. But tars actions while running a 2.6.21-rcX kernel > certainly are not. I do have a plain -rc2 I can try, so that will be the > next test. If that also fails in this manner, I'll build a later > 2.6.20-2 or whatever to verify that it doesn't so suffer. You may find 'strace' useful to track down this sort of thing (though the output can be voluminous). -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Gene Heskett wrote: >On Monday 12 March 2007, Con Kolivas wrote: >>Hi Gene. >> >>On Monday 12 March 2007 16:38, Gene Heskett wrote: >>> I hate to say it Con, but this one seems to have broken the >>> amanda-tar symbiosis. >>> >>> I haven't tried a plain 21-rc3, so the problem may exist there, and >>> in fact it did for 21-rc1, but I don't recall if it was true for >>> -rc2. But I will have a plain 21-rc3 running by tomorrow nights >>> amanda run to test. >>> >>> What happens is that when amanda tells tar to do a level 1 or 2, tar >>> still thinks its doing a level 0. The net result is that the tape is >>> filled completely and amanda does an EOT exit in about 10 of my 42 >>> dle's. This is tar-1.15-1 for fedora core 6. >> >>I'm sorry but I have to say I have no idea what any of this means. I >> gather you're making an association between some application >> combination failing and RSDL cpu scheduler. Unfortunately the details >> of what the problem is, or how the cpu scheduler is responsible, >> escape me :( > >I have another backup running right now, after building a plain >2.6.21-rc3, and rebooting just now for the test. I don't think its the >scheduler itself, but is something post 2.6.20 that is messing with tars >mind and making it think the files it just read to do the estimate > phase, are all new, so even a level 2 is in effect a level 0. I'll > have an answer in about an hour, but its also 2:36am here and I'm > headed for the rack to get some zzz's. So I'll report in the morning > as to whether or not this backup ran as it was supposed to. I have a > feeling its not going to though. I can confirm that a plain 21-rc3 still suffers from this problem. This run of amanda terminated after 13 of the 32 dle's after writing just short of 12GB to the vtape. 8 were level 0's, 5 were level 1's, all were gzipped, achieving a compression ratio of 40% of original size. There is about 45GB of data here to backup, on a 5 day dumpcycle. If, and I have previously, I revert to a 2.6.20-ck1 patching, this does not occur. So my contention is that someplace in this recent progression from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how c-time is being reported to tar. Or there is a spillage into c-times when tar does its estimate scans where the output goes to /dev/null. Or possibly even this version of tar is doing it differently. I just looked up how to get the c-times out of ls, and they, as far as ls is concerned, look sane. But tars actions while running a 2.6.21-rcX kernel certainly are not. I do have a plain -rc2 I can try, so that will be the next test. If that also fails in this manner, I'll build a later 2.6.20-2 or whatever to verify that it doesn't so suffer. I love your patches Con, but I'll leave them out of this next testing. No use pointing fingers at good code. -- 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) Mal: "Well, you were right about this being a bad idea." Zoe: "Thanks for sayin', sir." --Episode #1, "Serenity" - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Gene Heskett wrote: On Monday 12 March 2007, Con Kolivas wrote: Hi Gene. On Monday 12 March 2007 16:38, Gene Heskett wrote: I hate to say it Con, but this one seems to have broken the amanda-tar symbiosis. I haven't tried a plain 21-rc3, so the problem may exist there, and in fact it did for 21-rc1, but I don't recall if it was true for -rc2. But I will have a plain 21-rc3 running by tomorrow nights amanda run to test. What happens is that when amanda tells tar to do a level 1 or 2, tar still thinks its doing a level 0. The net result is that the tape is filled completely and amanda does an EOT exit in about 10 of my 42 dle's. This is tar-1.15-1 for fedora core 6. I'm sorry but I have to say I have no idea what any of this means. I gather you're making an association between some application combination failing and RSDL cpu scheduler. Unfortunately the details of what the problem is, or how the cpu scheduler is responsible, escape me :( I have another backup running right now, after building a plain 2.6.21-rc3, and rebooting just now for the test. I don't think its the scheduler itself, but is something post 2.6.20 that is messing with tars mind and making it think the files it just read to do the estimate phase, are all new, so even a level 2 is in effect a level 0. I'll have an answer in about an hour, but its also 2:36am here and I'm headed for the rack to get some zzz's. So I'll report in the morning as to whether or not this backup ran as it was supposed to. I have a feeling its not going to though. I can confirm that a plain 21-rc3 still suffers from this problem. This run of amanda terminated after 13 of the 32 dle's after writing just short of 12GB to the vtape. 8 were level 0's, 5 were level 1's, all were gzipped, achieving a compression ratio of 40% of original size. There is about 45GB of data here to backup, on a 5 day dumpcycle. If, and I have previously, I revert to a 2.6.20-ck1 patching, this does not occur. So my contention is that someplace in this recent progression from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how c-time is being reported to tar. Or there is a spillage into c-times when tar does its estimate scans where the output goes to /dev/null. Or possibly even this version of tar is doing it differently. I just looked up how to get the c-times out of ls, and they, as far as ls is concerned, look sane. But tars actions while running a 2.6.21-rcX kernel certainly are not. I do have a plain -rc2 I can try, so that will be the next test. If that also fails in this manner, I'll build a later 2.6.20-2 or whatever to verify that it doesn't so suffer. I love your patches Con, but I'll leave them out of this next testing. No use pointing fingers at good code. -- 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) Mal: Well, you were right about this being a bad idea. Zoe: Thanks for sayin', sir. --Episode #1, Serenity - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett [EMAIL PROTECTED] writes: If, and I have previously, I revert to a 2.6.20-ck1 patching, this does not occur. So my contention is that someplace in this recent progression from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how c-time is being reported to tar. Or there is a spillage into c-times when tar does its estimate scans where the output goes to /dev/null. Or possibly even this version of tar is doing it differently. I just looked up how to get the c-times out of ls, and they, as far as ls is concerned, look sane. But tars actions while running a 2.6.21-rcX kernel certainly are not. I do have a plain -rc2 I can try, so that will be the next test. If that also fails in this manner, I'll build a later 2.6.20-2 or whatever to verify that it doesn't so suffer. You may find 'strace' useful to track down this sort of thing (though the output can be voluminous). -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: If, and I have previously, I revert to a 2.6.20-ck1 patching, this does not occur. So my contention is that someplace in this recent progression from 2.6.20 to 2.6.21-rc3, there is a patch which acts to change how c-time is being reported to tar. Or there is a spillage into c-times when tar does its estimate scans where the output goes to /dev/null. Or possibly even this version of tar is doing it differently. I just looked up how to get the c-times out of ls, and they, as far as ls is concerned, look sane. But tars actions while running a 2.6.21-rcX kernel certainly are not. I do have a plain -rc2 I can try, so that will be the next test. If that also fails in this manner, I'll build a later 2.6.20-2 or whatever to verify that it doesn't so suffer. You may find 'strace' useful to track down this sort of thing (though the output can be voluminous). -Doug I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. -- 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'm definitely not in Omaha! - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: running /usr/local/sbin//amcheck Daily Amanda Tape Server Host Check - Holding disk /dumps: 72597 MB disk space available, using 72097 MB slot 5: read label `Dailys-5', date `20070223002502' NOTE: skipping tape-writable test Tape Dailys-5 label ok Server check took 4.556 seconds Amanda Backup Client Hosts Check WARNING: coyote: selfcheck request failed: unable to bind to a reserved port (got port 32789) Client check: 1 host checked in 34.733 seconds, 1 problem found (brought to you by Amanda 2.5.1p3-20070222) --eofsnip The script quit by request shortly after as I didn't want it to further dirty the amanda database system. -- 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) Safety Third. - 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: RSDL for 2.6.21-rc3- 0.29
On 3/12/07, Gene Heskett [EMAIL PROTECTED] wrote: On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: Can we start a new thread for this amanda issue? It does not seem to have anything to do with Con's scheduler... Lee - 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: RSDL for 2.6.21-rc3- 0.29
Gene Heskett [EMAIL PROTECTED] writes: On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: I'd do 'strace -ff -o /tmp/amanda-strace command', which will give you a set of files in /tmp, one for each PID created by fork(). Then find the one that has the 'tar' invocation you're looking for. -Doug - 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: RSDL for 2.6.21-rc3- 0.29
On Mon, Mar 12, 2007 at 03:43:09PM -0400, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: I'd do 'strace -ff -o /tmp/amanda-strace command', which will give you a set of files in /tmp, one for each PID created by fork(). Then find the one that has the 'tar' invocation you're looking for. Hi, I hope you don't mind me jumping in ... Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ That should be working, shouldn't it ? Cheers, Patrick - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Patrick Mau wrote: On Mon, Mar 12, 2007 at 03:43:09PM -0400, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: On Monday 12 March 2007, Douglas McNaught wrote: Gene Heskett [EMAIL PROTECTED] writes: I'd considered it, but with 32 dle entries, the whole strace output would be terrabytes I don't have THAT much disk. Not to mention it traces only the parent process, so tar would be merrily marching along to its own drummer and not traced I'm afraid. $ strace -ff -Doug Someone else suggested the single -f, and I tried that, but even with the shell history set for 100,000 lines, i can't get back to the start, and I think its mucking with the shell arguments numbering as what I can see is about 5 reads through /etc/services accompanied by endless complaints of -EBADFD, the the logfile it generates says the port it was given was rejected when amcheck was run, here is that snip: I'd do 'strace -ff -o /tmp/amanda-strace command', which will give you a set of files in /tmp, one for each PID created by fork(). Then find the one that has the 'tar' invocation you're looking for. Hi, I hope you don't mind me jumping in ... Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ That should be working, shouldn't it ? Cheers, Patrick It should I'd think, for those instances where these scripts are run by hand and therefore have a shell to output to. I'll give that a try when I get my script problem resolved, its a basic diff in the operation of real tapes and vtapes I need to get right for both scenarios. Good Idea(TM), 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) Ignorance is the soil in which belief in miracles grows. -- Robert G. Ingersoll - 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/
Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
Patrick Mau [EMAIL PROTECTED] writes: Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ You beat me to it. :) I've done that before; it's a great suggestion. Except that if you expect 'tar' to be invoked multiple times in a run, you should probably use 'output.$$' for the output filename so things don't get clobbered. -Doug - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Monday 12 March 2007, Douglas McNaught wrote: Patrick Mau [EMAIL PROTECTED] writes: Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ You beat me to it. :) I've done that before; it's a great suggestion. Except that if you expect 'tar' to be invoked multiple times in a run, you should probably use 'output.$$' for the output filename so things don't get clobbered. -Doug In my case, Doug, it will get invoked 64 times, amanda does a dummy run to get an estimate, calculates what to do based on that output which is 32 runs, 1 per disklist entry and I have 32, and then reruns tar with the appropriate level options against each individual disklist entry. But I'm puzzled a bit, what does the double $$ do?, or it buried someplace in the bash manpage? Its not something I've stumbled over yet. -- 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) rugged, adj.: Too heavy to lift. - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On 3/12/07, Gene Heskett [EMAIL PROTECTED] wrote: On Monday 12 March 2007, Douglas McNaught wrote: Patrick Mau [EMAIL PROTECTED] writes: Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ You beat me to it. :) I've done that before; it's a great suggestion. Except that if you expect 'tar' to be invoked multiple times in a run, you should probably use 'output.$$' for the output filename so things don't get clobbered. -Doug In my case, Doug, it will get invoked 64 times, amanda does a dummy run to get an estimate, calculates what to do based on that output which is 32 runs, 1 per disklist entry and I have 32, and then reruns tar with the appropriate level options against each individual disklist entry. But I'm puzzled a bit, what does the double $$ do?, or it buried someplace in the bash manpage? Its not something I've stumbled over yet. buried indeed: Special Parameters: ... $ Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the current shell, not the sub‐ shell. Thanks, Nish - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Monday 12 March 2007, Nish Aravamudan wrote: On 3/12/07, Gene Heskett [EMAIL PROTECTED] wrote: On Monday 12 March 2007, Douglas McNaught wrote: Patrick Mau [EMAIL PROTECTED] writes: Why not temporarly replace /bin/tar with a shell script that does: #!/bin/sh exec strace -f -o output /bin/real.tar $@ You beat me to it. :) I've done that before; it's a great suggestion. Except that if you expect 'tar' to be invoked multiple times in a run, you should probably use 'output.$$' for the output filename so things don't get clobbered. -Doug In my case, Doug, it will get invoked 64 times, amanda does a dummy run to get an estimate, calculates what to do based on that output which is 32 runs, 1 per disklist entry and I have 32, and then reruns tar with the appropriate level options against each individual disklist entry. But I'm puzzled a bit, what does the double $$ do?, or it buried someplace in the bash manpage? Its not something I've stumbled over yet. buried indeed: Special Parameters: ... $ Expands to the process ID of the shell. In a () subshell, it expands to the process ID of the current shell, not the sub‐ shell. Well, that's clear enough, but what of the double $$ case? Would this them make a PID unique to each invocation untill it finally wraps a 16 bit value, or will the kernel re-use them because they won't all be running simultainiously, but limited by the number of unique 'spindle' numbers on the system, this to prevent as best as it can, the thrashing of a drive by having tar working on 2 separate (or more) partitions at the same time. In my case 2 are possible, as /var is on a separate drive. Thanks, Nish -- 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) Say yur prayers, yuh flea-pickin' varmint! -- Yosemite Sam - 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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Tue, Mar 13, 2007 at 12:04:42AM -0400, Gene Heskett wrote:
On Monday 12 March 2007, Nish Aravamudan wrote:
On 3/12/07, Gene Heskett [EMAIL PROTECTED] wrote:
On Monday 12 March 2007, Douglas McNaught wrote:
Patrick Mau [EMAIL PROTECTED] writes:
Why not temporarly replace /bin/tar with a shell script that
does:
#!/bin/sh
exec strace -f -o output /bin/real.tar $@
You beat me to it. :) I've done that before; it's a great
suggestion.
Except that if you expect 'tar' to be invoked multiple times in a
run, you should probably use 'output.$$' for the output filename so
things don't get clobbered.
-Doug
In my case, Doug, it will get invoked 64 times, amanda does a dummy
run to get an estimate, calculates what to do based on that output
which is 32 runs, 1 per disklist entry and I have 32, and then reruns
tar with the appropriate level options against each individual
disklist entry.
But I'm puzzled a bit, what does the double $$ do?, or it buried
someplace in the bash manpage? Its not something I've stumbled over
yet.
buried indeed:
Special Parameters:
...
$ Expands to the process ID of the shell. In a ()
subshell, it expands to the process ID of the current shell, not
the sub?$B! shell.
Well, that's clear enough, but what of the double $$ case? Would this
them make a PID unique to each invocation untill it finally wraps a 16
bit value, or will the kernel re-use them because they won't all be
running simultainiously, but limited by the number of unique 'spindle'
numbers on the system, this to prevent as best as it can, the thrashing
of a drive by having tar working on 2 separate (or more) partitions at
the same time. In my case 2 are possible, as /var is on a separate
drive.
Yes there a risk of wrapping, but it is very small. You can add the command
line arguments to the file name if you want, like this :
#!/bin/sh
exec strace -f -o output.$$.${*//\//_} /bin/real.tar $@
It will name the output file output.pid.args, replacing slashes with
underscores. This is very dirty but can help.
Cheers,
Willy
-
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: Stracing Amanda (was: RSDL for 2.6.21-rc3- 0.29)
On Tuesday 13 March 2007, Willy Tarreau wrote:
On Tue, Mar 13, 2007 at 12:04:42AM -0400, Gene Heskett wrote:
On Monday 12 March 2007, Nish Aravamudan wrote:
On 3/12/07, Gene Heskett [EMAIL PROTECTED] wrote:
On Monday 12 March 2007, Douglas McNaught wrote:
Patrick Mau [EMAIL PROTECTED] writes:
Why not temporarly replace /bin/tar with a shell script that
does:
#!/bin/sh
exec strace -f -o output /bin/real.tar $@
You beat me to it. :) I've done that before; it's a great
suggestion.
Except that if you expect 'tar' to be invoked multiple times in a
run, you should probably use 'output.$$' for the output filename
so things don't get clobbered.
-Doug
In my case, Doug, it will get invoked 64 times, amanda does a dummy
run to get an estimate, calculates what to do based on that output
which is 32 runs, 1 per disklist entry and I have 32, and then
reruns tar with the appropriate level options against each
individual disklist entry.
But I'm puzzled a bit, what does the double $$ do?, or it buried
someplace in the bash manpage? Its not something I've stumbled
over yet.
buried indeed:
Special Parameters:
...
$ Expands to the process ID of the shell. In a ()
subshell, it expands to the process ID of the current shell,
not the sub?$B! shell.
Well, that's clear enough, but what of the double $$ case? Would this
them make a PID unique to each invocation untill it finally wraps a 16
bit value, or will the kernel re-use them because they won't all be
running simultainiously, but limited by the number of unique 'spindle'
numbers on the system, this to prevent as best as it can, the
thrashing of a drive by having tar working on 2 separate (or more)
partitions at the same time. In my case 2 are possible, as /var is on
a separate drive.
Yes there a risk of wrapping, but it is very small. You can add the
command line arguments to the file name if you want, like this :
#!/bin/sh
exec strace -f -o output.$$.${*//\//_} /bin/real.tar $@
It will name the output file output.pid.args, replacing slashes
with underscores. This is very dirty but can help.
Excellent Willy, thanks.
Cheers,
Willy
--
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)
Whatever doesn't succeed in two months and a half in California will
never succeed.
-- Rev. Henry Durant, founder of the University of California
-
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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Con Kolivas wrote: >Hi Gene. > >On Monday 12 March 2007 16:38, Gene Heskett wrote: >> I hate to say it Con, but this one seems to have broken the amanda-tar >> symbiosis. >> >> I haven't tried a plain 21-rc3, so the problem may exist there, and in >> fact it did for 21-rc1, but I don't recall if it was true for -rc2. >> But I will have a plain 21-rc3 running by tomorrow nights amanda run >> to test. >> >> What happens is that when amanda tells tar to do a level 1 or 2, tar >> still thinks its doing a level 0. The net result is that the tape is >> filled completely and amanda does an EOT exit in about 10 of my 42 >> dle's. This is tar-1.15-1 for fedora core 6. > >I'm sorry but I have to say I have no idea what any of this means. I > gather you're making an association between some application > combination failing and RSDL cpu scheduler. Unfortunately the details > of what the problem is, or how the cpu scheduler is responsible, escape > me :( I have another backup running right now, after building a plain 2.6.21-rc3, and rebooting just now for the test. I don't think its the scheduler itself, but is something post 2.6.20 that is messing with tars mind and making it think the files it just read to do the estimate phase, are all new, so even a level 2 is in effect a level 0. I'll have an answer in about an hour, but its also 2:36am here and I'm headed for the rack to get some zzz's. So I'll report in the morning as to whether or not this backup ran as it was supposed to. I have a feeling its not going to though. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "When it comes to humility, I'm the greatest." -- Bullwinkle Moose - 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: RSDL for 2.6.21-rc3- 0.29
Hi Gene. On Monday 12 March 2007 16:38, Gene Heskett wrote: > I hate to say it Con, but this one seems to have broken the amanda-tar > symbiosis. > > I haven't tried a plain 21-rc3, so the problem may exist there, and in > fact it did for 21-rc1, but I don't recall if it was true for -rc2. But > I will have a plain 21-rc3 running by tomorrow nights amanda run to test. > > What happens is that when amanda tells tar to do a level 1 or 2, tar still > thinks its doing a level 0. The net result is that the tape is filled > completely and amanda does an EOT exit in about 10 of my 42 dle's. This > is tar-1.15-1 for fedora core 6. I'm sorry but I have to say I have no idea what any of this means. I gather you're making an association between some application combination failing and RSDL cpu scheduler. Unfortunately the details of what the problem is, or how the cpu scheduler is responsible, escape me :( -- -ck - 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: RSDL for 2.6.21-rc3- 0.29
On Sunday 11 March 2007, Con Kolivas wrote: >On Sunday 11 March 2007 15:03, Matt Mackall wrote: >> On Sat, Mar 10, 2007 at 10:01:32PM -0600, Matt Mackall wrote: >> > On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote: >> > > Ok I don't think there's any actual accounting problem here per se >> > > (although I did just recently post a bugfix for rsdl however I >> > > think that's unrelated). What I think is going on in the ccache >> > > testcase is that all the work is being offloaded to kernel threads >> > > reading/writing to/from the filesystem and the make is not getting >> > > any actual cpu time. >> > >> > I don't see significant system time while this is happening. >> >> Also, it's running pretty much entirely out of page cache so there >> wouldn't be a whole lot for kernel threads to do. > >Well I can't reproduce that behaviour here at all whether from disk or > the pagecache with ccache, so I'm not entirely sure what's different at > your end. However both you and the other person reporting bad behaviour > were using ATI drivers. That's about the only commonality? I wonder if > they do need to yield... somewhat instead of not at all. I hate to say it Con, but this one seems to have broken the amanda-tar symbiosis. I haven't tried a plain 21-rc3, so the problem may exist there, and in fact it did for 21-rc1, but I don't recall if it was true for -rc2. But I will have a plain 21-rc3 running by tomorrow nights amanda run to test. What happens is that when amanda tells tar to do a level 1 or 2, tar still thinks its doing a level 0. The net result is that the tape is filled completely and amanda does an EOT exit in about 10 of my 42 dle's. This is tar-1.15-1 for fedora core 6. -- 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) While it may be true that a watched pot never boils, the one you don't keep an eye on can make an awful mess of your stove. -- Edward Stevenson - 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: RSDL for 2.6.21-rc3- 0.29
On Sunday 11 March 2007, Con Kolivas wrote: On Sunday 11 March 2007 15:03, Matt Mackall wrote: On Sat, Mar 10, 2007 at 10:01:32PM -0600, Matt Mackall wrote: On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote: Ok I don't think there's any actual accounting problem here per se (although I did just recently post a bugfix for rsdl however I think that's unrelated). What I think is going on in the ccache testcase is that all the work is being offloaded to kernel threads reading/writing to/from the filesystem and the make is not getting any actual cpu time. I don't see significant system time while this is happening. Also, it's running pretty much entirely out of page cache so there wouldn't be a whole lot for kernel threads to do. Well I can't reproduce that behaviour here at all whether from disk or the pagecache with ccache, so I'm not entirely sure what's different at your end. However both you and the other person reporting bad behaviour were using ATI drivers. That's about the only commonality? I wonder if they do need to yield... somewhat instead of not at all. I hate to say it Con, but this one seems to have broken the amanda-tar symbiosis. I haven't tried a plain 21-rc3, so the problem may exist there, and in fact it did for 21-rc1, but I don't recall if it was true for -rc2. But I will have a plain 21-rc3 running by tomorrow nights amanda run to test. What happens is that when amanda tells tar to do a level 1 or 2, tar still thinks its doing a level 0. The net result is that the tape is filled completely and amanda does an EOT exit in about 10 of my 42 dle's. This is tar-1.15-1 for fedora core 6. -- 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) While it may be true that a watched pot never boils, the one you don't keep an eye on can make an awful mess of your stove. -- Edward Stevenson - 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: RSDL for 2.6.21-rc3- 0.29
Hi Gene. On Monday 12 March 2007 16:38, Gene Heskett wrote: I hate to say it Con, but this one seems to have broken the amanda-tar symbiosis. I haven't tried a plain 21-rc3, so the problem may exist there, and in fact it did for 21-rc1, but I don't recall if it was true for -rc2. But I will have a plain 21-rc3 running by tomorrow nights amanda run to test. What happens is that when amanda tells tar to do a level 1 or 2, tar still thinks its doing a level 0. The net result is that the tape is filled completely and amanda does an EOT exit in about 10 of my 42 dle's. This is tar-1.15-1 for fedora core 6. I'm sorry but I have to say I have no idea what any of this means. I gather you're making an association between some application combination failing and RSDL cpu scheduler. Unfortunately the details of what the problem is, or how the cpu scheduler is responsible, escape me :( -- -ck - 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: RSDL for 2.6.21-rc3- 0.29
On Monday 12 March 2007, Con Kolivas wrote: Hi Gene. On Monday 12 March 2007 16:38, Gene Heskett wrote: I hate to say it Con, but this one seems to have broken the amanda-tar symbiosis. I haven't tried a plain 21-rc3, so the problem may exist there, and in fact it did for 21-rc1, but I don't recall if it was true for -rc2. But I will have a plain 21-rc3 running by tomorrow nights amanda run to test. What happens is that when amanda tells tar to do a level 1 or 2, tar still thinks its doing a level 0. The net result is that the tape is filled completely and amanda does an EOT exit in about 10 of my 42 dle's. This is tar-1.15-1 for fedora core 6. I'm sorry but I have to say I have no idea what any of this means. I gather you're making an association between some application combination failing and RSDL cpu scheduler. Unfortunately the details of what the problem is, or how the cpu scheduler is responsible, escape me :( I have another backup running right now, after building a plain 2.6.21-rc3, and rebooting just now for the test. I don't think its the scheduler itself, but is something post 2.6.20 that is messing with tars mind and making it think the files it just read to do the estimate phase, are all new, so even a level 2 is in effect a level 0. I'll have an answer in about an hour, but its also 2:36am here and I'm headed for the rack to get some zzz's. So I'll report in the morning as to whether or not this backup ran as it was supposed to. I have a feeling its not going to though. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) When it comes to humility, I'm the greatest. -- Bullwinkle Moose - 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/
