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
