DDS3, ufsdump, blocking factor.

DDS3, ufsdump, blocking factor.

Post by Philippe Mazeran » Wed, 16 Feb 2000 04:00:00



Hi,

On my server in Solaris 2.6, I have a Sun DDS-3 tape drive (HP C1537A).

When I'm dumping my systems files, I usually save between 12G-14G
(ufsdump
with the default parameters).
It doesn't seems to be the best I can expect with this tape drive (given
for 12G-24G).
The systems files are "classic" (user's files, system, software, ...),
not full of
compressed files.
I heart that the blocking factor has no longer an effect with the
ufsdump, but I didn't
find any confirmation of it.

Is anybody got some urls or information about the ideal parameters for
this
tape drive/ufsdump ?

Thanks,
Philippe.


 
 
 

DDS3, ufsdump, blocking factor.

Post by Mike Spoone » Wed, 16 Feb 2000 04:00:00




Quote:> Hi,

> On my server in Solaris 2.6, I have a Sun DDS-3 tape drive (HP C1537A).

> When I'm dumping my systems files, I usually save between 12G-14G
> (ufsdump
> with the default parameters).
> It doesn't seems to be the best I can expect with this tape drive (given
> for 12G-24G).
> The systems files are "classic" (user's files, system, software, ...),
> not full of
> compressed files.
> I heart that the blocking factor has no longer an effect with the
> ufsdump, but I didn't
> find any confirmation of it.

The software-level blocking factor for DAT drives is not a major factor
these
days - the drives do the real blocking themselves, internally, using an
adaptive algorithm.

There are two settings that will make a huge difference...

First, the drive's internal
blocking-factor, set using options in /kernel/drv/st.conf (try "man st") -
DDS-3
drives can handle very large block sizes (over 1Mb).

Then there is the "software" blocking factor (actually the read/write sizes
used
by ufsdump/ufsrestore). These should be set to match the drive's internal
setting.

If you need help figuring out what to do to with st.conf, email me at

- Show quoted text -

> Is anybody got some urls or information about the ideal parameters for
> this
> tape drive/ufsdump ?

> Thanks,
> Philippe.




 
 
 

1. SCO tar error on block size (not block factor)

Someone recommended:
tar cvfb - ./config 32768 | compress | dd of=/dev/rmt/0m bs=32k  
tar: invalid blocksize. (Max 20)
0+1 records in
0+1 records out

Seeing his/her error i supposed that what they meant was the actual
block
size in bytes to match the 'dd' record size.  But
tar cvfB -  ./config 32768  | compress | dd of=/dev/rmt/0m bs=32k
tar: B: unknown option
Usage: tar -{txruc}[0-9vfbkelmnopwAFLTP] [tapefile] [blocksize]
[tapesize] files...
        Key     Device            Block   Size(K)    Tape
        0       /dev/rfd048ds9    18      360        No    
        1       /dev/rfd148ds9    18      360        No    
        2       /dev/rfd096ds15   10      1200       No    
        3       /dev/rfd196ds15   10      1200       No    
        4       /dev/rfd0135ds9   18      720        No    
        5       /dev/rfd1135ds9   18      720        No    
        6       /dev/rfd0135ds18  18      1440       No    
        7       /dev/rfd1135ds18  18      1440       No    
        8       /dev/rct0         20      0          Yes    
        9       /dev/rctmini      20      0          Yes    
        10      /dev/rdsk/fp03d   18      720        No    
        11      /dev/rdsk/fp03h   18      1440       No    
        12      /dev/rdsk/fp03v21 10      20330      No  

Is there a way to get tar to match the 'dd' record size please?
--

have
access to a news server; thanks!
Disclaimer: opinions expressed my own and not representative of my
employers

2. Problem with X starting then stopping

3. block size vs. blocking factor

4. REPOST: gdb can't read Linux ELF core dump (still unsolved)

5. DAT blocking factor & tapetool

6. NFS mount

7. tape blocking factors

8. efax problem

9. blocking factor for qic wide?

10. tar tape blocking factor

11. tar blocking factor

12. ufsrestore, I think a blocking factor problem

13. DDS-3 blocking factor