Do you think this failed because my holding disk is 11 GB and I was trying
to dump/write 10 GB at the same time? Could it have bottle-necked? Files
reading in and writing out - checksum failure?
On Mon, 11 Dec 2000, John R. Jackson wrote:
> >driver: dumping admin1.corp.walid.com:sda10 directly to tape
> >driver: send-cmd time 3970.608 to taper: PORT-WRITE 00-00017
> >admin1.corp.walid.com sda10 0 20001209
> >driver: result time 3970.619 from taper: PORT 34331
> >driver: send-cmd time 3970.619 to dumper0: PORT-DUMP 01-00018 34331
> >admin1.corp.walid.com sda10 0 1970:1:1:0:0:0 DUMP |;bsd-auth;index;
> >driver: state time 3970.619 free kps: 12209 space: 5861972 taper: writing
> >idle-dumpers: 3 qlen tapeq: 0 runq: 0 stoppedq: 0 wakeup: 86400
> >driver-idle: not-idle
> >driver: interface-state time 3970.619 if : free 6809 if HME0: free 10000
> >if LE0: free 10000 if LOCAL: free 10000
> >driver: hdisk-state time 3970.619 hdisk 0: free 5861972 dumpers 0
>
> This says sda10 was being dumped directly to tape when the world ended.
> I don't know why the file is truncated at this point, but it looks like
> the system was rebooted, or the disk this file is part of filled up,
> or the Amanda user ran into its disk quota, or something like that.
>
> There is no trail of why the sda10 disk failed to make it entirely
> to tape.
>
> Is the "40" in your tapetype name meant to imply this device can do
> 40 GBytes? Is that compressed or "native"? If it's the manufactures
> compressed number, they lie, big time. The usual numbers they give are
> the native and twice the native for hardware compression. For instance,
> my DLT7000's are 35 GBytes native, so they claim 70 GBytes if I use
> hardware compression. But back here in the real world, I only get about
> 37 GBytes.
>
> >Denise E. Ives
>
> John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
>
--
Denise E. Ives [EMAIL PROTECTED]
Systems Engineer 734.822.2037
Multilingual Internet Domain Name Registrations - http://www.walid.com
