> We use ufsdump to backup our file systems to 8 mm, > 4mm or DAT 72 tape drives. The default blocking > factor ufsdump uses is 64 (without b or c option) and > the problem with this is the amount of data that can > fit on a tape because of the IRG.
Does the IRG really cause a substantial difference in the capacity? > My questions are: > > - how can I find out the optimum blocking factor (or > that is supported) for each tape device > (8mm/4mm/DAT72)? I would suppose you'd just go as high as you can if you're trying to optimize for space. > - what are the issues of changing the blocking factor > to 512 (ufsdump code seems to cap the blocking factor > to 512)? Older operating systems might not be able to deal with very large factors. A factor of 126 was commonly used because some old OS's broke at 128. I don't know if anything has a problem there now. For smaller tapes or smaller files on tape, you're wasting space in the final block because it is likely that more of it will be unused with a large block size. Also 'ufsdump' and the tape have their own blocks. I imagine it's setting them to be the same, but I haven't tried to confirm that. You could reblock with 'dd' or something even if the ufsdump code were limiting. ufsdump 0f - /source | dd of=/path/to/tape obs=<blocksize> You'd probably need to reverse that on restoration, because ufsrestore isn't going to know to use a larger blocksize for reading (you'll get an "out of space" error). -- Darren This message posted from opensolaris.org _______________________________________________ ufs-discuss mailing list [email protected]
