rg@gandp (Dick Gill) (02/23/91)
A client with a 32/650 (2.1.1) with about 880MB on-line disc
capacity (about 747MB used) recently purchased an NCR 8mm tape
drive (6091-2001-7190) with the thought that they could easily
back up their entire system to a single tape. That's what I
thought when I sold it to them, but I now have real doubts.
First some facts. The current status of the discs (from df -t)
is:
/usr/acct1 (/dev/dsk/15s1): 50972 blocks 64937 i-nodes
total: 572320 blocks 65488 i-nodes
/usr/acct (/dev/dsk/14s1): 36688 blocks 60763 i-nodes
total: 572320 blocks 65488 i-nodes
/ (/dev/dsk/38s1): 179462 blocks 54000 i-nodes
total: 616874 blocks 65488 i-nodes
The tapes being used are 376 foot 8mm tapes from Exabyte (NCR
supplies does not have these tapes!!) Exabyte says that this is
the longest tape made for this drive.
The backup is run from crontab and uses cpio in a script that
has worked for me for years. (I did have to remove blocking
through dd to get it to run with the drive)
Now the story. When the drive was first installed, their disc
usage was slightly higher than now, and they got error 28's (I
think I remember this correctly) near the end of the backup.
CODAR mulled it over for a couple days and finally decided
that the problem was that the "sparse" (aka "holely") files on
the system were being expanded by cpio and thus exceeding the
capacity of the tape. While some large files of that type are
on the system, I had not experienced this problem before with
backups to regular 9-track or casette tapes.
Still, something was fishy; I didn't see how these files would
drive the tape past its (advertised) capacity of 2.1GB. To
quote the NCR product writeup, "..this tape drive uses compact
cartridges to store up to 2.1 Gigabytes of user data on one tape
(maximum formatted capacity)."
To get a better handle on the problem, I said:
dd if=/dev/rmt/1yy of=/dev/null
and, when I got the results 6 hours later, guess what? EOF
occurs at about 1.5 GB; got the same result with another new
tape! Is this right? Where is the missing 0.6 GB of capacity?
Inquiring minds (including my client) want to know.
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Dick Gill Gill & Piette, Inc. (703)761-1163 ..uunet!gandp!rg
wescott@Columbia.NCR.COM (Mike Wescott) (02/24/91)
In article <343@gandp> rg@gandp.UUCP (Dick Gill) writes: > The backup is run from crontab and uses cpio in a script that > has worked for me for years. (I did have to remove blocking > through dd to get it to run with the drive) > To get a better handle on the problem, I said: > > dd if=/dev/rmt/1yy of=/dev/null > > and, when I got the results 6 hours later, guess what? EOF > occurs at about 1.5 GB; got the same result with another new > tape! Is this right? Where is the missing 0.6 GB of capacity? Possibly, the blocking factor is too small and to keep streaming the exabyte pads with extra blocks (actually rewrites blocks). The same thing happens with streaming tapes. -- -Mike Wescott mike.wescott@ncrcae.Columbia.NCR.COM
jalsop@seachg.uucp (John Alsop) (02/26/91)
In article <1991Feb23.175824.537@nncrcae.Columbia.NCR.COM> wescott@Columbia.NCR.COM (Mike Wescott) writes: >In article <343@gandp> rg@gandp.UUCP (Dick Gill) writes: >> The backup is run from crontab and uses cpio in a script that >> has worked for me for years. (I did have to remove blocking >> through dd to get it to run with the drive) > >> To get a better handle on the problem, I said: >> >> dd if=/dev/rmt/1yy of=/dev/null >> >> and, when I got the results 6 hours later, guess what? EOF >> occurs at about 1.5 GB; got the same result with another new >> tape! Is this right? Where is the missing 0.6 GB of capacity? > >Possibly, the blocking factor is too small and to keep streaming >the exabyte pads with extra blocks (actually rewrites blocks). >The same thing happens with streaming tapes. >-- The Exabyte drive automatically switches between streaming and start/stop mode, depending on the rate at which data is supplied to it. It needs to get around 250K per second in order to stream. This is around 15MB per minute, and your Tower is unlikely to be supplying data that fast, especially using cpio. 2-4 MB/minute is more likely. When the tape drive stops writing data, it will write a "gap track", which wastes about 10K of tape capacity. However, the drive does have an on-board 240K buffer, which means that data will be written to the tape in 240K chunks. So you will probably lose about 10k capacity for each 240k block written to tape. This is only about 4% of the tape capacity, and doesn't explain the loss you are seeing. (Note: the onboard buffer can be disabled by the device driver, but I can't think why anyone would want to do this). My guess is that the cause of your capacity loss is poor tape quality, resulting in rewritten data. We have seen significant variations in tape capacity from one cartridge to the next. Exabyte branded tapes are no better than Sony tapes in this respect. The exabyte drive maintains statistics on read/write error counts - I don't know whether NCR's driver can display them or not. -- John Alsop Sea Change Corporation 6695 Millcreek Drive, Unit 8 Mississauga, Ontario, Canada L5N 5R8 Tel: 416-542-9484 Fax: 416-542-9479 UUCP: ...!uunet!attcan!seachg!jalsop