On Friday 31 July 2009, Gene Heskett wrote:
Greetings;
Built/installed with no config changes, 1st run with a 1GB smaller spec for
the vtape.
At 7:45 in the morning it is still going, and it is usually finished by
around 2 am.
Asking for an 'amstatus Daily' stops after printing the date, and
On Friday 31 July 2009, Dustin J. Mitchell wrote:
On Fri, Jul 31, 2009 at 1:09 PM, Gene Heskettgene.hesk...@verizon.net
wrote:
Should that be something that an amcheck /config/ could have caught?
No, not necessarily -- note the skipping tape-writeable test (which
had the side-effect of erasing
Greetings;
Built/installed with no config changes, 1st run with a 1GB smaller spec for
the vtape.
At 7:45 in the morning it is still going, and it is usually finished by around
2 am.
Asking for an 'amstatus Daily' stops after printing the date, and is now using
99% of the cpu. Killable with
On Fri, Jul 31, 2009 at 9:11 AM, Gene Heskettgene.hesk...@verizon.net wrote:
Your turn. :)
Can you send me the whole taper log with all of the repeats in it? or
at least the first few MB of it? I suspect there are a few bugs
conspiring here..
Dustin
--
Open Source Storage Engineer
On Friday 31 July 2009, Dustin J. Mitchell wrote:
On Fri, Jul 31, 2009 at 9:11 AM, Gene Heskettgene.hesk...@verizon.net
wrote:
Your turn. :)
Can you send me the whole taper log with all of the repeats in it? or
at least the first few MB of it? I suspect there are a few bugs
conspiring here..
On Fri, Jul 31, 2009 at 9:47 AM, Gene Heskettgene.hesk...@verizon.net wrote:
No, 100% PEBKAC. Somehow the slot9 directory got owned by root, so even if
the link 'data' was owned by amanda, amanda had no perms for the target of the
link. I just put the 730 snapshot back in after the flush was
On Friday 31 July 2009, Dustin J. Mitchell wrote:
On Fri, Jul 31, 2009 at 9:47 AM, Gene Heskettgene.hesk...@verizon.net wrote:
No, 100% PEBKAC. Somehow the slot9 directory got owned by root, so even
if the link 'data' was owned by amanda, amanda had no perms for the target
of the link. I just
Ah, I see what happened -- the tape doesn't get overwritten, so the
taperscan assumes that it is still useable and feeds it back to the
taper. Rinse, wash, repeat.
I'll get this fixed up, then.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
On Friday 31 July 2009, Dustin J. Mitchell wrote:
Ah, I see what happened -- the tape doesn't get overwritten, so the
taperscan assumes that it is still useable and feeds it back to the
taper. Rinse, wash, repeat.
I'll get this fixed up, then.
Dustin
Sounds good to me. ;)
--
Cheers, Gene
On Friday 31 July 2009, Dustin J. Mitchell wrote:
Ah, I see what happened -- the tape doesn't get overwritten, so the
taperscan assumes that it is still useable and feeds it back to the
taper. Rinse, wash, repeat.
I'll get this fixed up, then.
Dustin
Should that be something that an amcheck
On Fri, Jul 31, 2009 at 1:09 PM, Gene Heskettgene.hesk...@verizon.net wrote:
Should that be something that an amcheck /config/ could have caught?
No, not necessarily -- note the skipping tape-writeable test (which
had the side-effect of erasing the tape)
Dustin
--
Open Source Storage Engineer
11 matches
Mail list logo
