Re: dd gets tape native capacity, amanda (sometimes) dosen't
2002-08-10 00:32:21
Pulling individual lines from a long message:
On Fri, Aug 09, 2002 at 03:37:32PM -0600, Will Aoki wrote:
> Some nights, to some tapes, my backups run fine. I get about 8 GB dumped
> to tape:
>
> But other days, to other tapes, I run out of tape at about 5 GB:
>
Note this line from your failed report:
> taper: tape umnh-20011112-1 kb 9590432 fm 33 writing file: No space left on
> device
It says 9.6GB of data plus 33 file marks were written before the error. Not
5GB.
Now, your file system by file system list shows an output size (after
compression)
of 5.3GB plus one failed file system. Those 5.3GB were "successfully written"
as
evidenced by the completed "taper" statistics.
My guess about the failed entry is that it is a very large file system, more
than 4GB
after compression.
Further, I think there is insufficient holding disk space to receive that
system dump.
Thus it was being dumped directly to tape. I say this because there is no
dumper
data. A dump to the holding disk must complete before transfer to tape begins.
As
taping was in progress, yet there is no dumper data, the dump must be going
directly
to tape. Otherwise there would be dumper data and dumps left on the holding
disk
available for amflush.
Basically some days you are backing up more data than a single tape can hold
and are not
using multiple tapes per run. Plus, some of your systems will not fit the
holding disk.
About the holding disk space, how big is it and what percent is "reserved"?
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
|
|