On Thu, 13 Mar 2003 at 9:53am, wab wrote

> It's obviously this I/O error that's causing the problem... the
> filesystem is 67 gig (df -k says 67108864 1048-K blocks). The other
> filesystems being backed up to the tape only are using 3-4% of tape
> capacity... and it's a DLT 40/80. The compression ratio seems like all
> this should fit on 1 tape:
> 
> STATISTICS:
>                           Total       Full      Daily
>                         --------   --------   --------
> Dump Time (hrs:min)       28:15      25:04       0:08   (1:18 start,
> 1:46 idle)
> Output Size (meg)        1205.4        0.0     1205.4
> Original Size (meg)      3534.7        0.0     3534.7
> Avg Compressed Size (%)    33.9        --        33.9

That compression ratio is only from the filesystems that were successfully 
backed up.  The ration can change *drastically* based on the fs contents.  

> but maybe it's possible this 67-gig filesystem is filling my DLT tape
> up, it reaches the end of the tape, and it I/O errors? If so I need to
> do some math (blech) to determine how much data we can get rid of on
> this big filesystem...

Again, the I/O errors were reported by tar, and so come from reading from 
disk, not writing to tape (which tar isn't doing).

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University