Very Computer

Hello,

we use a TLZ06 with 2GB DATs for backups. Now I have a 2 GB disk that is almost
full but according to the SHOW DEVICE there should be still 350 MB of free
space. Nevertheless BACKUP requires a second tape. Any ideas why?
I know I can enable compression, but I thought as long as there are less than
2 GB of space occupied on the disk I don't need compression. Am I wrong?

$ BACKUP/NOLOG/NOCRC/IGNORE=INTERLOCK/NOASSIST -
  /IMAGE DISK9: MKB300:27JAN95D9.BCK -
  /SAVE_SET/LABEL=D901/REWIND/RELEASE_TAPE

$ SET NOVERIFY
%MOUNT-I-MOUNTED, D901 mounted on _MPI4$MKB300:
%BACKUP-I-RESUME, resuming operation on volume 2
%MOUNT-I-OPRQST, Please mount volume D90102 in device _MPI4$MKB300:
BACKUP requests: Saveset 27JAN95D9.BCK, Volume number 02, write ENABLED

Disk MPI2$DKA500:, device type Generic SCSI disk, is online, mounted, file-
    oriented device, shareable, available to cluster, error logging is enabled.

    Error count                    0    Operations completed              15403
    Owner process                 ""    Owner UIC                      [SYSTEM]
    Owner process ID        00000000    Dev Prot    S:RWED,O:RWED,G:RWED,W:RWED
    Reference count                1    Default buffer size                 512
    Total blocks             4178874    Sectors per track                    81
    Total cylinders             2716    Tracks per cylinder                  19
    Host name                 "MPI2"    Host type, avail   VAXstation 3100, yes

    Volume label             "DISK9"    Relative volume number                0
    Cluster size                   5    Transaction count                     1
    Free blocks               957945    Maximum files allowed            348239
    Extend quantity                5    Mount count                           4
    Mount status              System    Cache name      "_MPI1$DKB300:XQPCACHE"
    Extent cache size             64    Maximum blocks in extent cache    95794
    File ID cache size            64    Blocks currently in extent cache      0
    Quota cache size             200    Maximum buffers in FCP cache        935

  Volume status:  subject to mount verification, file high-water marking, write-
      through caching enabled.
  Volume is also mounted on MPI4, MPI3, MPI2.

Magtape MPI4$MKB300:, device type TLZ6, is online, allocated, record-oriented
    device, file-oriented device, error logging is enabled, loader present,
    controller supports compaction (compaction  disabled).

    Error count                    0    Operations completed             180389
    Owner process        "BATCH_150"    Owner UIC                         [0,0]
    Owner process ID        21E00204    Dev Prot    S:RWED,O:RWED,G:RWED,W:RWED
    Reference count                2    Default buffer size                   4
    Density                  unknown    Format                        Normal-11

  Volume status:  no-unload on dismount, beginning-of-tape, odd parity.

Regards,
   Christoph Gartmann

+----------------------------------------------------------------------------+
| Max-Planck-Institut fuer      Phone   : +49-761-5108-465   Fax: -221       |
| Immunbiologie                 PSI     : PSI%(0262)45050160374::GARTMANN    |

| D-79011  Freiburg, FRG                                                     |
+----------- Do you know MENUE, the user environment for OpenVMS? -----------+

        we use a TLZ06 with 2GB DATs for backups. Now I have a 2 GB disk that
        is almost full but according to the SHOW DEVICE there should be still
        350 MB of free space. Nevertheless BACKUP requires a second tape. Any
        ideas why?  I know I can enable compression, but I thought as long as
        there are less than 2 GB of space occupied on the disk I don't need
        compression. Am I wrong?

        $ BACKUP/NOLOG/NOCRC/IGNORE=INTERLOCK/NOASSIST -
          /IMAGE DISK9: MKB300:27JAN95D9.BCK -
          /SAVE_SET/LABEL=D901/REWIND/RELEASE_TAPE

        [Further information shows 3220929 blocks = about 1.6GB in use on the
        disk.]

BACKUP is writing a redundancy group:  Every 11th block is the XOR of the
previous 10.  This in and of itself adds another 160 meg of data.  There is
also additional overhead information that BACKUP has to record; it's hard to
quantify that.  You can eliminate this overhead with /GROUP:0, but I wouldn't
recommend it - you do presumably want some assurance that you can read the
data back, I suppose.  Using /GROUP:0 disables an important BACKUP recovery
mechanism.  (And, while we are at it, /NOCRC is also interfering with BACKUP's
ability to recover from a damaged tape or flakey hardware.  While it's true
that BACKUP's CRC calculation isn't as valuable on today's drives as it used
to be, it's also true that the greater CPU speed of today's machines, combined
with a more efficient implementation, have made the cost of computing it
insignificant in many if not most cases.  In your position, I'd at least try
removing the /NOCRC.)

That's the pure software side of things.  On the hardware side, a "2GB" DAT
will hold 2GB under "ideal" conditions.  Space is wasted on the tape to mark
the ends of blocks.  Since you haven't specified a block size, the BACKUP
default for tapes of 8464 bytes is used.  For a DAT tape, this is a small
value and will waste a fair amount of space.  I've seen various recommenda-
tions for block sizes for DAT drives, but haven't really experimented myself.
Some devices seem to do better when the block size is an exact multiple of 8K,
as I recall.  In any case, you should certainly try a larger block size - you
might even go all the way up to the BACKUP limit of 65534.

All in all, however, you're skating on the edge.  Measurements like "2GB" are
never exact, and always over-simplified.  Even if you squeeze today's backup
onto one tape, tomorrow's may be just enough larger not to make it.  On the
other hand, with compression enabled, things should fit with no trouble at
all.  Unless you have concerns about reading compressed tapes on other systems
with older drives, or something like that, you might as well use it.

                                                        -- Jerry

Quote:>Hello,

>we use a TLZ06 with 2GB DATs for backups. Now I have a 2 GB disk that is almost
>full but according to the SHOW DEVICE there should be still 350 MB of free
>space. Nevertheless BACKUP requires a second tape. Any ideas why?
>I know I can enable compression, but I thought as long as there are less than
>2 GB of space occupied on the disk I don't need compression. Am I wrong?

>$ BACKUP/NOLOG/NOCRC/IGNORE=INTERLOCK/NOASSIST -
>  /IMAGE DISK9: MKB300:27JAN95D9.BCK -
>  /SAVE_SET/LABEL=D901/REWIND/RELEASE_TAPE

You may have 2GB of data on the tape.  Of course, some of that 2GB of data on
the tape is BACKUP's overhead inside the saveset.  

If you have a 1GB disk that is absolutely full, it'll take more than 1GB worth
of tape to back it up.  There's some overhead data written in the BACKUP
saveset that takes up space.  In some cases, this overhead data can be
significant.  My calculations indicate that you have 1.65GB of disk space in
use.  If the overhead is 20%, then you're going to be awfully close to the 2GB.
Then, you need to take the ANSI tape labels into account.  Then, there may be
the issue of bad spots on the tape.

I believe the 2GB capacity of the drive also assumes you're running 90m tapes.

+===================+=========================+================================+



|      /  /   /   / +=========================+================================+
| /___/  /_  /___/\ |     Opinions expressed here are mine, and mine alone     |
+===================+==========================================================+

The default overhead is 1 redundancy group for every 10 groups.  You can
reduce that to nothing, or make it 100%.

The problem here is block sizes.  If backup is writing 8K blocks on DAT,
then the IRG occuring must be consuming a large amount of space.  On a
TU/TA78, a full sized reel at 6250 would hold abourt 105 meg at 8K
blocks, and close to 141 meg in 64K blocks (there being 7 fewer IRG's per
64K).
--
Guy Sherr   MCI "keep it on the tracks" Engineer
(214) 918-2791

I am confused.  I either espoused company policy,
or I just caught a deep fly ball to left field.

You need to increase the block size to something much bigger than the default.
I use /blocksize=65000.  You also should enable compaction by:
INIT/MEDIA=COMPACTION
MOUNT/FOR/MEDIA=COMPACTION
BACKUP/IMAGE/MEDIA=COMPACTION.

These commands will permit up to 4GB to be put on the 90M tape.
BACKUP savesets are usually 10% larger than the data stored on tape.  BACKUP
was not meant to compress data, it was meant to permit error free recovery of
data from error prone media.  Thus is needs extra information to be able to
recover fom various error
s.