On Wed, Oct 13, 2010 at 11:01 AM, McGraw, Robert P wrote:
> In the past I have had problem with the man pages shipped with amanda. With
> 3.1.2 this seemed to be fine. I could even run
What kind of package are you using?
> Now with 3.1.3 I am back to the shipped man pages not working. If I run
On Wed, Oct 13, 2010 at 10:08 AM, Jon LaBadie wrote:
> Surprisingly, the amanda-match(7) manpage is not included
> in the pre-built binaries I've installed (version 3.1.2-1).
I added it in 3.2
> However the installed amanda(8) manpage does include the
> same "Host and Disk Expression" section as
On Wed, Oct 13, 2010 at 12:25 AM, Jon LaBadie wrote:
> I wonder if a syntax extension that would be backward compatible is
> possible. Blue-skying here, maybe a single argument with a separator
> between host and disk. Something like 'host|disk' or 'host/disk'.
For those playing along at home,
On Tue, Oct 12, 2010 at 10:53 PM, Jon LaBadie wrote:
> The manpage Amanda(8) where "Host and Disk Expression"
> are documented indicates some wildcarding is allowed.
> Thus, for a host where I wanted all DLEs excpet one
> that began with the letter "A" I tried:
>
> amdump host '[!A]*'
>
>
On Fri, Oct 8, 2010 at 10:11 AM, Dustin J. Mitchell wrote:
> Does such a configuration exist? I thought your config was named "HANSA"?
Did you sort this out?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
looks like they did...
On Mon, Oct 11, 2010 at 1:03 PM, McGraw, Robert P wrote:
> 2010-10-09 23:10:45 hertz /gauss/export/users-w 0 A00184
> 1 1/1 OK
> 2010-10-09 23:10:45 hertz /gauss/export/users-w 0 A00180
> 6 1/-1 PARTIAL PARTIAL
D
On Mon, Oct 11, 2010 at 10:47 AM, McGraw, Robert P wrote:
> hertz -ss/export/users-w 0 50143 50143 -- PARTIAL
> 25:45 33234.0
>
> says that when it went to the next tape that the complete {user-a, users-m,
> users-w} were written on the next tape.
Actually, all th
On Sat, Oct 9, 2010 at 4:02 PM, Gunnarsson, Gunnar
wrote:
> Sat Oct 9 22:23:08 2010: amgtar: Spawning "/usr/local/bin/tar
> /usr/local/bin/tar --create --verbose --file - --directory /
> --one-file-system --no-check-device --listed-incremental
> /var/opt/lib/amanda/gnutar-lists/hansabck_1.new
On Sat, Oct 9, 2010 at 12:22 PM, Gunnarsson, Gunnar
wrote:
> ok then I must overide the tapetype def with -o option in the amvault command.
I'm not sure about that. Your amvault run demonstrated that your
tapes can actually hold almost 6 times the data you've suggested in
your default tapetype.
On Sat, Oct 9, 2010 at 8:21 AM, Gunnarsson, Gunnar
wrote:
>>OK. You should adjust the length in your tapetype definition, then - your
>>tape appears to be at least 550% longer than you have configured.
>
> Can I add the tape length to:
>
> define changer vault {
No, it needs to be in the tapety
On Fri, Oct 8, 2010 at 5:42 PM, Gunnarsson, Gunnar
wrote:
> No is a HP Ultrium LTO 3 tape drive:
>
> Yes I think the data was written to tape I will verify that next week.
OK. You should adjust the length in your tapetype definition, then -
your tape appears to be at least 550% longer than you h
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
wrote:
> Is this because amvault is considered a flush ?
..
> *** THE DUMPS DID NOT FINISH PROPERLY!
No, it was a bug - amvault didn't write the "FINISH driver" line
before calling amreport, so amreport didn't think it was finished.
> Tape usage
On Fri, Oct 8, 2010 at 1:07 PM, John Hein wrote:
> I have a client with an amandad that has been running since Sep 23...
..
> 2000 APPLICATION 36
> |;auth=BSD;compress-fast;index;exclude-file=.no-amanda-backup;exclude-file=.nobak;exclude-file=.noback;exclude-file=.nodump;
I would avoid BSD a
On Fri, Oct 8, 2010 at 1:11 PM, Gunnarsson, Gunnar
wrote:
> Is this because amvault is considered a flush ?
>
> Tape usage statistic is rather odd as well.
Can you send the trace log that generated this report?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Fri, Oct 8, 2010 at 12:26 PM, Brian Cuttler wrote:
> I realize that there IS NO Solution within amanda. This is a capacity
> planning issue for the humans to solve, but amanda can warn via the
> amdump report, that problems are imminent and that human capacity
> planning is required.
Well, by
On Fri, Oct 8, 2010 at 10:24 AM, Brian Cuttler wrote:
> Feature request (?) - There are checks for DLE > tape, seems almost
> silly but a check for
> SUM(DLEs) > (tape_capacity * runtapes)
One DLE with a full size larger than available tape is always a
Thanks for the tip about --autolabel any, by the way. I accidentally
implemented it as --autolabel all. The fix is easy :)
On Fri, Oct 8, 2010 at 11:17 AM, Gunnarsson, Gunnar
wrote:
> ok this will vault all full dumps in my configuation but can I select only
> the most resent for each filesyst
On Fri, Oct 8, 2010 at 9:01 AM, Gunnarsson, Gunnar
wrote:
> I'm vaulting from config hansa and I'm getting parse error about hansa-vault
> config ?
Does such a configuration exist? I thought your config was named "HANSA"?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Fri, Oct 8, 2010 at 8:40 AM, McGraw, Robert P wrote:
> Dustin, thanks very much for your help in resolving this.
Sure thing. Jean-Louis has, in the interim, fixed the problem of not
being able to eject when a fatal error occurs in the tape device. So
this one is fixed twice :)
Dustin
--
O
On Fri, Oct 8, 2010 at 4:19 AM, Gunnarsson, Gunnar
wrote:
> Good work releasing beta3. Few thing that come to my mind while testing
> amvault regarding slections of dumps.
Maybe I'm misunderstanding "come to mind", but these are all possible
now. Have I failed to document these well enough? Or
On Thu, Oct 7, 2010 at 11:01 AM, McGraw, Robert P wrote:
> I had been using 2048KB, which I had defined in "tapetype", when I was
> running Amanda 2.x and never got this error.
Yes, it's a new error for something that used to be handled quietly.
Basically, the kernel takes the 2MB write and bre
On Thu, Oct 7, 2010 at 1:49 AM, Titl Erich wrote:
> I guess this finding should give you something to chew on
Indeed! If I'm reading the hex dumps correctly, then, the first file
is padded at the beginning with exactly 28424 bytes of zero. The file
lengths differ by the same quantity. Can you
Thank you to everyone who tested beta2 - we caught a number of bugs,
none of which are huge, which gives me confidence that the upcoming
3.2.0 release will be a sturdy one.
As promised[1], we have another beta release available this morning.
Please test! Those of you who have been holding off on
On Wed, Oct 6, 2010 at 10:10 AM, Jon LaBadie wrote:
> Again, if trying from the server, might this be yet another
> tar version incompatibilities?
This is unlikely, but worth checking out all the same - can the
version of tar that amrecover is using successfully extract the
amfetchdump'd tarfiles
On Tue, Oct 5, 2010 at 5:01 PM, Charles Curley
wrote:
> Done. I also upgraded to amanda-3.2.0beta1.svn.3489.tar.gz, per today's
> announcement. I just ran 15 amchecks in a row, then an amdump, and no
> problems.
Great!
I should be clear - and I'll reiterate in tomorrows beta2 announcement
- 3.2.
On Tue, Oct 5, 2010 at 1:33 PM, McGraw, Robert P wrote:
> hertz /gauss/export/users-s lev 0 partial taper: Error writing block:
> Mysterious short write on tape device: Tried 2097152, got 1052672
>
> as amanda hit the end of tape.
.. and you're using a block size (2M) that's bigger than your t
We're planning another beta tomorrow, so if you have anything you'd
like to see fixed in that beta, let me know ASAP. That includes
manpage typos and other actual nitpicks :)
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The Amanda development team has discovered a security vulnerability
introduced
in Amanda-3.1.2. The vulnerability affects both Amanda servers and
clients,
and could lead to remote execution of code as the Amanda user.
The problem is fixed in Amanda-
On Tue, Oct 5, 2010 at 11:39 AM, mezzie wrote:
> The logs here are on a different date than the original post but I have
> verified that it is still happening for the files attached.
So it looks like mvsu.edu:/home/tk20/fileshighered is a problematic DLE.
Looking at when that particular DLE was
On Tue, Oct 5, 2010 at 9:29 AM, Jean-Louis Martineau
wrote:
> The value of '-1' show that something is corrupted, the backup image is
> probably not valid, that's why you can't restore it.
> Can you post the complete log..0, the amdump.? log file and the
> dumper.*.debug file.
You're right - this
On Mon, Oct 4, 2010 at 10:30 PM, Charles Curley
wrote:
> I plan to go back to tcp and auth=bsdtcp once I get this issue solved.
> Of course it could be that making those changes will solve this issue.
I'd recommend that. I consider BSD and BSDUDP authentications to be
legacy backward-compatibili
On Mon, Oct 4, 2010 at 9:45 PM, Charles Curley
wrote:
> I'm no expert on configure, so that could be wrong. BTW, are the
> options for configure documented anywhere?
Only in ./configure --help. It looks like you got things figured out, though.
> That done, I was able to get an amckeck, a backup
On Mon, Oct 4, 2010 at 3:28 PM, Charles Curley
wrote:
> Understandable. Yes, useradd should set it up correctly. However, on
> debian and Ubuntu, the default user directory, /var/backups, is already
> created by the time you run make install, and so is the backup user.
> And debian uses that direc
On Mon, Oct 4, 2010 at 2:09 PM, Charles Curley
wrote:
> It might be nice if the installation process not only made the directory
> but changed its ownership to the amanda user.
The only reason that Amanda references its home directory is for
.amandahosts, which is modeled on .rhosts (and you've a
On Mon, Oct 4, 2010 at 1:59 AM, Gunnarsson, Gunnar
wrote:
> Yes I hope so. What version should I go for ?
This - or rather a version improved by Jean-Louis' suggestion to print
the more precise "flush successfully retried" - will be in the next
3.2.0 beta, which we're considering releasing midwee
Incidentally, I can't help but notice that you're backing up disks
named /var/amanda/amandatapes/ems/slotNN. Will amvault be able to
help you out? If so, could you find some time to test it before I set
sail in a week and a half?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Sun, Oct 3, 2010 at 1:46 PM, Gunnarsson, Gunnar
wrote:
> Yes this is much better - log is attached.
Fixed up in
http://github.com/djmitche/amanda/commit/z12092.patch
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Sun, Oct 3, 2010 at 5:37 PM, Stefan G. Weichinger wrote:
> applies and seems to work. encrypted DLE dumped.
Great! I'll wait to hear back from Jean-Louis about the potential
memory leak, then, before committing.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Sun, Oct 3, 2010 at 4:30 PM, Stefan G. Weichinger wrote:
> Sorry, it doesn't apply when using my amanda-3.2.0_beta1.ebuild ;-(
>
> Will look into it tomorrow.
There's a version rebased onto the 3.2.0_beta1 tag at
http://github.com/djmitche/amanda/commit/z12066.patch
Dustin
--
Open Source
On Sat, Oct 2, 2010 at 5:16 PM, Dustin J. Mitchell wrote:
> OK, in trying to duplicate this, I'm getting dumper segfaults, which
> is probably the same bug -- it looks like dumper is printing random
> memory in the error message above. So consider it replicated - and
> I'l
On Sun, Oct 3, 2010 at 12:35 PM, Robert Heller wrote:
> One of the downsides of using a very *stable* Linux distro with long
> term stable support. OTOH, it avoids the fun of re-installing
> everything every 6-12 months and then spending a couple of months
> getting all of the settings tweaked ju
On Sun, Oct 3, 2010 at 11:01 AM, Robert Heller wrote:
> Also I am pretty much stuck with 2.5.0, since that is what comes with
> CentOS... (I don't at this point want to 'experiment' with a bleeding
> edge self-built package, not for something like this.)
Yikes, you may be *very* out of luck, then
On Sun, Oct 3, 2010 at 10:26 AM, Gunnarsson, Gunnar <
gunnar.gunnars...@svk.se> wrote:
> It is reported as failed see below and those parts are added twice -
> filesystem 66 parts 68.
> In earlier version it is reported correctly.
>
Perhaps this is a change in behavior, but I think that this vers
On Sat, Oct 2, 2010 at 5:01 PM, Robert Heller wrote:
> I picked a 'virtual' tape size to match the capacity of a DVD-R: 4.3Gig,
> with the idea of migrating the fulls and the more major incrs to DVD-Rs
> for long-term archival.
Ah! You should take a look at both the dvdrw device (for writing to
On Sun, Oct 3, 2010 at 7:22 AM, Gunnarsson, Gunnar
wrote:
> I upgraded Amanda version from 2.6.1 to 3.1.2 and amreport reports:
...
> But they are written on the next tape, I'm not using tape spanning.
OK .. so what's the problem?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Thu, Sep 30, 2010 at 12:33 PM, Stefan G. Weichinger wrote:
> ? encrypt: dumper: error: couldn't exec server encryptionÈÏ HÃ 8 .
OK, in trying to duplicate this, I'm getting dumper segfaults, which
is probably the same bug -- it looks like dumper is printing random
memory in the error message
On Sat, Oct 2, 2010 at 1:03 PM, Jon LaBadie wrote:
> When running "amtape --help" the "usage" message
> is printed twice.
A *real* nitpick! Cool!
Fix is here:
http://github.com/djmitche/amanda/commit/z12091
If that works for you, let me know and I will commit. You should be
able to apply it
On Sat, Oct 2, 2010 at 2:46 PM, Robert Heller wrote:
> So I would be better off setting runtapes to 1? And then manually
> 'flushing' at the beginning of the cycle to deal with the larger fulls?
>
> Arg...
>
> This sort of thing is not really well explained in the man pages...
True. The problem
On Sat, Oct 2, 2010 at 9:15 AM, Jon LaBadie wrote:
>> runtapes 2 # number of tapes to be used in a single run of amdump
>
> I hope very few dumps take more than one tape, like none :)
To be clear on the planner's reasoning: it considers itself to have
runtapes * tapetype:length kb available to pl
On Sat, Oct 2, 2010 at 9:21 AM, Jon LaBadie wrote:
> Thinking about a recent post caused me to wonder
> about the bumpdays directive. Is it truely
> measured in "days" as opposed to "amdump runs"?
Neither, actually - it's measured in tapes / runtapes. So if your
runtapes is large but seldom rea
FYI, in 3.2.0beta1 amvault always uses a part size of 2MB, which can
cause *huge* logfiles for large (or even medium-sized) dumps.
This is an oversight on my part, and I'll get it fixed up, but in the
interim, don't vault anything too large in 3.2.0 or your logfiles will
get huge and thus your rec
As promised, we have the first beta version of Amanda-3.2.0 out today.
It's available from
http://www.zmanda.com/download-amanda.php (binary packages; version
3.2.0beta1)
http://amanda.org/download.php (tarball; under "Development")
The more testing this release can get, the better. And the
On Wed, Sep 29, 2010 at 1:51 PM, Gene Heskett wrote:
> Wed Sep 29 14:41:23 2010: amcheck-device: set_current: symlinking
> /amandatapes/test/data to slot1
And is this link in place on the filesystem now? What's the
difference between the 14:31 and 14:41 runs of amcheck?
Dustin
--
Open Source
On Wed, Sep 29, 2010 at 12:53 PM, Chris Nighswonger
wrote:
> Line 473 should have a double colon rather than a single... ie.
> Amanda::Debug::debug rather than Amanda::Debug::debug
Sorry about that, Gene. You can just edit the file under /usr, rather
than re-making Amanda, if that's easier.
Dus
On Wed, Sep 29, 2010 at 12:48 PM, Christian Kratzer wrote:
> it looks like I might have found the problem. Both windows hosts had
> the shadow copy service disabled. I startetd the service and will check
> tomorrows full dumps.
Can you post some info to the wiki about how to check and enable VS
On Wed, Sep 29, 2010 at 11:33 AM, Gene Heskett wrote:
> Note the --with-config=Daily \, but the subdir when running am* Daily is
> /amandatapes/Dailys, note the plural. Is this line even required?
No, --with-config is largely ignored, and the name of the vtape
directory need not match the name
On Wed, Sep 29, 2010 at 11:46 AM, Valeriu Mutu wrote:
> What do you mean by "shoe-shining"?
shoe-shining is when a tape drive must stop the tape repeatedly while
it buffers more deta. It creates a lot of wear on the tape, and also
kills performance.
Dustin
--
Open Source Storage Engineer
http
On Wed, Sep 29, 2010 at 10:29 AM, Titl Erich wrote:
> Downloading the current snapshot, could you provide compiling and packaging
> information?
The instructions for compiling from a tarball are here:
http://wiki.zmanda.com/index.php/Installation/Installing_Amanda_Source
If you want to build a
On Wed, Sep 29, 2010 at 1:12 AM, Titl Erich wrote:
> It takes a while and I can observe data transfer with tcpdump.
OK, I suspect, then, that this is a timing-related bug in 3.1.2, that
is fixed in the 3_1 branch. Do you have the capacity to build from a
tarball on the server? I don't have any
On Wed, Sep 29, 2010 at 7:39 AM, Gene Heskett wrote:
> For S&G, I removed the data link from the test setup. Running amcheck test
> does restore it.
>
> Removing it from the running setup and running amcheck Daily does not. But
> it doesn't seem to effect amdump or amcheck in any way.
So we nee
On Tue, Sep 28, 2010 at 9:06 PM, Gene Heskett wrote:
> Anyway, its setup, and awaiting orders Cap'n. Next?
Can you replicate any of the failure-to-update-data errors with this
test config?
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Tue, Sep 28, 2010 at 6:26 PM, Gene Heskett wrote:
> I now see a 'data' link to slot 5, I nuked that 2 days ago because nothing
> was paying an attention to it, and neither amcheck nor amdump was updating
> it, and the loss causes no errors, none, nada, zip. My helper script no
> longer pays an
On Sun, Sep 26, 2010 at 6:03 PM, Dustin J. Mitchell wrote:
> That said, the new chg-disk *is* supposed to duplicate the data
> symlink quirk, so I'll take a look at why it's not doing that.
And I just verified that this works for me -- it's also tested for by
the installchec
When you do the recovery with amrecover, does it take a while for the
tar error to appear, or is it immediate? I'd like to figure out if
it's transferring any data at all.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Tue, Sep 28, 2010 at 12:21 AM, Jon LaBadie wrote:
> Including appropriate selinux policies for Fedora builds might
> be another feature enhancement request or "nitpick".
I'd like to see them, too, but I'm not sure how quickly they'd get out
of date. They'd need someone savvy in the ways of se
On Mon, Sep 27, 2010 at 12:05 PM, Titl Erich wrote:
> Here for your reference the outcome of amfetchdump does not look good
>
> subversion:/backup# amrecover
that's amrecover.
>> Is there any extra data in the dumpfile?
>
> Not that I know of. During amrecover I can observe the data stream and I
On Mon, Sep 27, 2010 at 1:12 AM, Titl Erich wrote:
> Just before you drop the ball completely, have you or someone else had time
> to look at the debug files
I had skimmed it briefly, and didn't see anything obvious. I suspect
that you've fixed the basic problem by changing FSF_AFTER_FILEMARK.
W
On Sun, Sep 26, 2010 at 4:34 PM, Gene Heskett wrote:
> Yes I did, but that didn't give me a clue that the 'data' link to whatever
> had been deprecated and that for cleanliness, I should go around an nuke
> it. No mention of it in the ChangeLog, I read it again early this morning
> from about the
On Sun, Sep 26, 2010 at 6:05 AM, Gene Heskett wrote:
> At some point in the last roughly a month, amanda stopped using the link
> named 'data' to point at the correct slot in a vtape directory.
I think you figured out, in a previous thread, that you switched to
the new chg-disk around the beginni
As we've hinted in various posts here, there's a lot of exciting new
stuff coming up in 3.2:
- multiple simultaneous tapers (!!)
- LEOM support (lossless splitting)
- new, simpler splitting parameters
- massive amvault improvements
- retirement of most old changers
- a great deal of code cle
On Thu, Sep 23, 2010 at 2:20 PM, Stefan G. Weichinger wrote:
> I would like to see it in my smaller installations as well, where there
> is no changer ...
Well, there's always a changer, but some of them (like chg-manual and
chg-single) do not support ejecting. That might be a good thing to
fix.
On Thu, Sep 23, 2010 at 1:28 PM, Stefan G. Weichinger wrote:
> A flag to set in amanda.conf to force an "mt -f $tapedev offl" after
> successful amdump/amflush ...
This has been a standing bug in Zmanda's bugzilla for a while, but
it's never become clear where this should happen. Changers alread
On Thu, Sep 23, 2010 at 9:08 AM, Gene Heskett wrote:
> Do I have editing rights on the wiki?
Everybody does (even spammers, ugh) - you may need to create an
account first, but that's easy. Here's the direct link:
http://wiki.zmanda.com/index.php?title=Special:UserLogin&type=signup&returnto=M
Stefan --
With the way the ebuild is structured right now, Amanda's built with
"dummy" manpages:
dus...@euclid ~/code/amanda/t/amanda [z11904 *] $ man amreport
DUMMY
You may want to consider adding configure flag --enable-manpage-build
to the ebuild, and adding
>=app-text/docbook-sxl-styleshee
On Thu, Sep 23, 2010 at 8:17 AM, Gene Heskett wrote:
> This discussion has been a positive, showing that there are indeed several
> ways to approach this problem, all of which, when TSHTF, contain the seeds
> for an expedited full recovery.
Great! This probably deserves a HowTo and/or FAQ on the
On Wed, Sep 22, 2010 at 8:05 PM, Christ Schlacta wrote:
> Why keep a backup server up 24/7 when it only works durring bakup hours?
Often the backup backup server is a server ordinarily devoted to other
purposes, with a few megs available for catalogs.
> Why not append the entire catalog to each
On Wed, Sep 22, 2010 at 10:07 AM, Jon LaBadie wrote:
> Any thoughts on how desireable you feel be a separate
> copy of amanda data would be and other approaches?
This comes up often, and I've never found a solution I'm happy enough
with to make the "official" solution.
Gene's approach is the obv
On Wed, Sep 22, 2010 at 3:17 AM, Titl Erich wrote:
> A few weeks ago I reported in the forum a problem with amrecover and
> compressed dump files. Meanwhile I changed to uncompressed backup, still no
> luck and, unfortunately not much replies either. So please bear with me when
> I repeat this her
On Mon, Sep 20, 2010 at 3:21 PM, Dustin J. Mitchell wrote:
> It's impractical to run this check in ./configure, but what do you
> think about running this check even on 'make all'?
I committed this - on FreeBSD, this test will occur on 'make install'.
> Do
On Tue, Sep 21, 2010 at 1:26 PM, Chris Nighswonger
wrote:
> This may be a little late, but it would be nice to have a switch on
> most status, etc. utils to format the output for texting to a mobile
> device rather than email.
Almost the exact same thing was requested earlier by Douglas K. Rand.
Gene, this is counterproductive at this point.
You've named a few things that seem to be wrong, all of which are
unrelated. You've changed things between each email, and claimed a
number of different symptoms.
PLEASE: slow down. Find *one* failure, describe it fully, and track
it down to its ca
On Mon, Sep 20, 2010 at 6:56 PM, Jon LaBadie wrote:
> Looks better to my eye. Any one else?
With Jean-Louis' review, committed in r3428. Thanks!
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Mon, Sep 20, 2010 at 11:20 PM, gene heskett wrote:
> with taper_debug 9 I had a 174 meg taper log, which still didn't make any
> sense as it was reporting about 6 lines for every 32k write, so I dropped
> it to 2. I grepped for the differences in the man tree but didn't see
> anything about th
On Thu, Sep 16, 2010 at 4:52 PM, Dustin J. Mitchell wrote:
> Are you working on this? Perhaps someone else on the list can jump in?
Hmm, well, I just took care of this:
http://github.com/djmitche/amanda/commit/z11908.patch
Total Full Incr. Le
On Mon, Sep 20, 2010 at 3:25 PM, Stefan G. Weichinger wrote:
> does that help?
Perhaps. I'm strongly suspecting that this is a problem with the new
multi-tape support. Jean-Louis, do you see anything related here?
I've upgrade my production Amanda to the latest trunk (thanks to the
handy-dandy
On Sun, Sep 19, 2010 at 4:48 PM, Stephen Corbesero wrote:
> That did it Or may have done it.
Sounds like this has worked out.
I had added a test to Amanda, which runs in 'make check' that should
have detected this:
536 thread-check: libTests.la
537 $(PERL) -I$(builddir) -I$(builddir
On Mon, Sep 20, 2010 at 2:44 PM, Stefan G. Weichinger wrote:
> Added that debug-parameter and re-ran amflush, nothing special in the logs.
What does this mean? Did the taper start up but not write anything?
And what revision are you using?
Dustin
--
Open Source Storage Engineer
http://www.zma
On Sun, Sep 19, 2010 at 11:05 PM, John Hein wrote:
> (Currently, I
> don't think the amanda client executes threaded code, but that may
> change in the future - or may have already in 3.1/3.2 code - Dustin?).
There is now a good bit of Perl running on the client side, but none
of it uses threads.
On Sun, Sep 19, 2010 at 7:00 PM, Gene Heskett wrote:
> But that kills amcheck, when amcheck is svn3341. How new do I have to be
> to have that work?
Oops, sorry, it's
debug_taper 9
not "debug taper"
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Thu, Sep 9, 2010 at 9:24 PM, Dustin J. Mitchell wrote:
> So I'm invoking my "that's complicated" escape clause. The only one
> of these that I could conceivably accomplish in the 3.2 timeframe is
> #2. I could add 'amadmin $conf hosts' to list all of
On Sun, Sep 19, 2010 at 5:40 PM, Gene Heskett wrote:
> Your guess is as good as mine, there simply isn't anything to indicate the
> failure, or a hint of a reason in the logs I've grepped. All I know at
> this point is that I have to back up to about svn3341 just to get amflush to
> work. The cu
On Sun, Sep 19, 2010 at 4:48 PM, Stephen Corbesero wrote:
> I upgraded my FreeBSD sources to the latest 8.x stable and recompiled
> the world (and kernel). I then compiled and installed Perl-5.10.1 for
> my FreeBSD by hand, specifically enabling its threaded option.
> Finally, I recompiled and re
On Sun, Sep 19, 2010 at 11:16 AM, Stephen Corbesero wrote:
> It still seems to hang right after the message about the 'Final
> linkage'. That is coming from the link_elements() subroutine in
> xfer-src/xfer.c.
Which is basically where the threading starts..
> I am not sure what to do next to ge
On Sun, Sep 19, 2010 at 5:32 AM, Gene Heskett wrote:
> One thing that catches my eye, in the taper.log, it is searching for:
> [ama...@coyote Daily]$ cat taper.20100919052724.debug
> Sun Sep 19 05:27:24 2010: taper: pid 5083 ruid 501 euid 501 version
> 3.2.0alpha.svn.3416: start at Sun Sep 19 05
On Sat, Sep 18, 2010 at 4:17 PM, Stephen Corbesero wrote:
> Also, if it is worth anything, the state of the process is listed as
> 'umtxn' from top/ps. (This is a FreeBSD 8.1 system.)
Huh, so that sounds like a kernel lock:
http://old.nabble.com/what-is-umtxn-td20860047.html
Can you identify
On Sat, Sep 18, 2010 at 3:35 PM, Stephen Corbesero wrote:
> (gdb) info threads
> * 1 Thread 28469480 (LWP 100148) 0x28af6225 in __error ()
> from /lib/libthr.so.3
Can you run the 'bt' command here to see what that thread is up to?
(gdb) bt
Dustin
--
Open Source Storage Engineer
http://
On Sat, Sep 18, 2010 at 2:17 PM, Jon LaBadie wrote:
> I'll certainly defer to you knowledge of the difficulty. I was thinking
> that the logic is already there for the split disk feature. The added
> code would be for saving its state and recreating it on the next flush.
Yes, that would be tric
On Sat, Sep 18, 2010 at 11:26 AM, Gene Heskett wrote:
> 1. The backup runs normally, to the holding disk, but times out writing to
> the vtape, so it is all left sitting in the holding disk. I have enough I
> can do this for several days.
Can you send the taper debug log? Taper doesn't "time ou
On Sat, Sep 18, 2010 at 9:44 AM, Jon LaBadie wrote:
> When a large DLE doesn't tape all the split parts
> before running out of tapes, could the subsequent
> flush (amflush or autoflush) pick up where the
> original taping left off?
>
> I just had a large DLE (23 3GB parts) fail on
> the last part
On Fri, Sep 17, 2010 at 8:35 PM, Gene Heskett wrote:
> At this point I have a WTH expression on my ancient face. Go read
> changelog if all else fails. I see a lot of changes on about 08/29-30-31
> but no mention of chg-disk-slot?
And, indeed, that hasn't changed.
Now that you've experimen
1 - 100 of 1267 matches
Mail list logo
