Hello,
first of all, thak's anyone for the help. The solution was to set
hardware compression ON on the TLZ07 drive and use not software
compression. There are /dev/nrmt0h, /dev/nrmt0m, /dev/nrmt0l and
nrmt0a devices. See manpage mtio(7) for more info. It speaks about high,
medium and low density of tape drives. So I don't see it related to
software compression. I don' know what the _a_ device. The _h_ device
seems to enable the compression DIP switch on the drive through software.
But someone suggested that probably the software commpression
features (compressasm) in networker are for compressing data
when backing up over the network. That was not our case.
Compressing data twice is inefficient. So best is HW compression and not
compression by software.
No-one knows what is the purpose of the Backup command option in
Client/Setup menu. More in mail from alan_at_nabeth.cxo.dec.com
So now I get 315kB/sec as a maximum, sometime 80kB/sec. I have to upgrade
from Networker 4.2C to 4.3 version(the patch is applied already).
But because I decided to remove the /devnrmt0h in networkers list of
devices while write to tape, networker crashed. When restarted, almost all
menus are shaded, and do not allow me to re-enter the device, even if it
still exists in /dev/nrmt0h! I can only connect to another Networker
server-I had only one. ;-) So I will have to re-install it? :-(
********************************* Original
reports:
alan_at_nabeth.cxo.dec.com wrote:
The sustained data transfer rate of the TLZ07 is 810 MB/sec
with hardware compression (probably 2:1). That is as "around"
1 MB/sec as you're going to get. After that it depends on
Networker and your data. Older versions of Networker treated
all local backups much like network backups, using an IPC
mechanism of some sort rather than reading and writing data
for local backups. It was a consistent technique, but slow.
I don't recall what version fixed this, but I think it was
after V4.2.
The next problem that a backup will have with respect to
performance is the time to open/read/close the files. Vdump
and Network use the file system interface to backup files.
If your file systems are mostly small files, the time to
open and close the file will dominate the time to read it,
and in turn slow down the backup.
Particular to Networker, each file needs a record of its
backup, which may slow down the backup some.
To get a feel for how quickly you can backup a particular
file system, use vdump and write the output to stdout with
that directed to /dev/null. This will be close to the
minimal time to backup the file system. In general, if the
hardware offers compression, use it in place of host
compression (which vdump and Networker both offer I think).
If the data already compress, don't use either. Compression
algorithms generally don't mix.
The 'h' device is hardware compression on. The other devices
(l,a,m) depend on the particular tape drive. For those you'll
want to check the mtio or SCSI manual pages.
Whether or not to use compress (of any kind) depends on the
data. If the data is already compressed (GIF files, GZIP,
or compress(1)), don't. If the data isn't compressed, you're
probably best off with hardware compression. NSR also offers
compression, but that is best used when doing network clients
to reduce the amount of network traffic.
The October 1997 Software Product Library distribution has
Networker V4.3 on it. I don't know whether the group handling
the DEC Campus distribution make their own with whatever they
feel is the appropriate version or if they distribution some
version of the SPL. The SPL label is"
"Digital UNIX Alpha Software Product Library"
I think it was Networker V4.3 that had the performance
improvements.
re: Backup command.
Only the vaguest clue. I read (2nd hand) that Networker supports
application specific backup programs. This might be the means of
running such an alternate backup. The problem is that you're
likely to lose Networker's cataloging ability. I've never gone
through all the Networker documentation, so I don't know what the
feature does. If it is a support feature, then it should be
documented somewhere. And, if it isn't documented, it probably
not something that has been throughly tested.
iglesias_at_draco.acs.uci.edu
There's a patch for DU 4.0B to make NSR 4.2C work better. Here's the
patch info:
(Patch ID: OSF410-400176-1)
PROBLEM: (QAR 36779) (Patch ID: OSF410-400298-1 reference information)
********
This patch fixes a problem that occurs when running the NetWorker
Version 4.2c application. The NetWorker application is unable to
reset the atime (access time) attribute on files being accessed. No
errors or warnings are displayed.
Without this patch, NetWorker Version 4.2c will not perform well.
That patch is in the jumbo patch 5, as part of patch OSFPAT00023100410.
<Robert.Otterson_at_digital.com>
Because I didn't specify if I was backing up over network or internally,
Robert suggested:
Lower your ipmtu if too large, I ran into a problem with this.
"ifconfig fta0 ipmtu 1492" (I think thats the command)
<CCao_at_exapps.com>
If you have compressasm on client, you're software compressed.
Take some time and find out the exact device for compression and you're
all set.
I prefer foregoing soft and enable hard compression.
Thanks also to Tom for his response.
Tom Ozanich <txo_at_esca.com>
Martin
-------------------------------------------------------------------------
| Martin MOKREJS - Net&SysAdmin |
| PGP 5.0i key at: finger://mail.natur.cuni.cz/mmokrejs |
| mmokrejs_at_natur.cuni.cz Faculty of Science, The Charles University |
| tel.: +420-2-2195 2315 Albertov 6, PRAGUE 2, 128 43, Czech Republic |
-------------------------------------------------------------------------
Received on Fri Nov 28 1997 - 23:40:24 NZDT