Two weeks ago I posted the following query:
We have a new 14GB Exebyte drive (from Sun, in one of their enclosures,
which they call an 'XT' type). OS: SunOS4.1.3_U1, Sys: SPARC 20. We are
having random difficulties backup up with 'dump', which we do not experience
with an older Exebyte 8500. We are trying to backup about 10-16 MB (one or
two tapes' worth) from a script which uses, as I say, 'dump'. Perhaps our
difficulty springs from not using the right blocking factors and so on. We
do not specify any of these, nor are we using hardware data compression.
Any suggstions as to the best way to use 'dump' on one of these drives?
Here is a summary of the most helpful responses. 'Me too's and 'Read the man
page' (etc.) are not included. My heartfelt thanks to my respondents.
-------------------------------------------------------------------------------
From: bdamicro!scott@Sun.COM (Scott Abrutyn)
I use this with our 14GB-maybe it will help...
$DUMPCMD 0dsbfu 54000 13000 126 $DUMPDEVICE /dev/dsk/c1t0d0s6
-------------------------------------------------------------------------------
From: colin@mtb.phil.mop.com (Colin Kubota)
We were having similar problems. We were told to change the tapes device from
/dev/rst0 or /dev/rst1 to /dev/rst16 and things have been working fine.
-------------------------------------------------------------------------------
From: dbrown@bev.etn.com (Darrin Brown)
I also picked up one the new 14gb tape drives and wanted to use it's full
capacity.
Turns out in order to get the full 14gb capacity - You must firstly use
160 meter tapes. You can only get 10gb on a std 112 meter tape with these
tape drives.
As far as dump goes - the trick is in the tape length, density parameters,
and specified device.
Use the following params in conjuction with a 160 meter tape and specifying
the high capacity logical device. ( If using the first tapedrive on the first
scsi controller - the low density dev would be /dev/rst0 and the high would be
/dev/rst16 )
[ example for a level 0 dump ]
dump 0fuds ${TAPE_DEV} 54000 47500 ${DISK_DEVICE}
The following script works well from cron running a level 0 dump of every
filesystem on the local machine to a single tape. The argument for TAPE_DEV
in this case must be non rewinding. ( i.e. /dev/nrst16 ). Obviously this
script will run un-attended only if you have > 14gb of local storage.
#!/bin/csh
setenv TAPE_DEV $1
mt -f ${TAPE_DEV} rewind
foreach DEVICE (`cat /etc/fstab | grep "4.2" | awk '{print $1}'`)
dump 0fuds ${TAPE_DEV} 54000 47500 ${DISK_DEVICE}
end
mt -f ${TAPE_DEV} rewoffl
Hope this helps ............
-------------------------------------------------------------------------------
From: Ray Brownrigg <Ray.Brownrigg@isor.vuw.ac.nz>
...The parameters I use for this drive are:
dump bdsf 126 54000 6000 /dev/nrst1 ...
However the largest file system I have is 1.3GB, and so those parameters
work for me, but they may not work for a partition larger than about
2GB. The general rule is to try a set of parameters and see how many
tapes dump says it is going to use, then adjust the density and/or size
so that the estimate is correct for the size of the file system (e.g.
if you have a 4GB file system, you expect it to use 0.71 tapes).
-------------------------------------------------------------------------------
From: nobroin@esoc.esa.de (Niall O Broin x 3619)
Dear John,
I'm sorry - I don't love you any more. Oops - wrong Dear John letter !
But seriously folks, there are a number of things to be aware of when trying to
use the XL drive, particularly with SunOS 4.1.3. Firstly, do you have your
kernel correctly configured to support this drive, as it doesn't do so out of
the box. If this is not the case, the following extract from the
comp.sys.sun.admin FAQ may be of some assistance...
Modify /sys/scsi/targets/st_conf.c before, after, or between the 8200.
Insert the following:
/* Exabyte 8mm 5GB cartridge w/compression*/ \
{
"Exabyte EXB-8505 8mm Helical Scan", 16, "EXABYTE EXB-8505",
ST_TYPE_EXB8500, 1024,
(ST_VARIABLE | ST_BSF | ST_BSR | ST_LONG_ERASE | ST_KNOWS_EOD),
5000, 5000,
{ 0x14, 0x15, 0x8c, 0x8c },
{ 0, 0, 0, 0 }
},
Once you've remade your kernel it appears as 4 different devices:
/dev/rst0 - 2.3Gb (8200 mode)
/dev/rst8 - 5Gb (8500 mode)
/dev/rst16 - 5Gb compressed (8500c mode)
/dev/rst24 - 5Gb compressed (8500c mode)
The above assumes tape drive is installed at the default SCSI id.
For dumping, you want to get maximum capacity from the drive, so use
/dev/rst24 which tells the drive to use compressed mode. But now the question
arises as to what parameters to use ? For Solaris, this is supposedly not a
problem, as the dump program (ufsdump) can detect end of media. However,
SunOS dump cannot and the idea of the dump parameters is to let dump
calculate the capacity of each tape and then decide for itself when it needs
a new tape, but this only works when one dump splits across multiple
tapes. If, as is the case with SunOS and high capacity drives, you are
dumping multiple filesystems one after another to the non-rewinding tape
device, dump has NO WAY of knowing how much of the tape has been already
used, so there's nothing for it but human intervention i.e. you have to
figure out how many of your filesystems will fit on one tape, and all that
the dump parameters do is tell dump that it has lots of space left.
Recommended values of density and size for 5 GB Exabytes are 54000 and 13000
and for the 10 GB Exabytes it is recommended to just double one of
these. However, for the reasons I've mentioned earlier, it hardly matters
what you tell dump, just as long as these parameters convince dump that the
"tape" (because in the middle of a multi filesystem dump, you're not dumping
to a tape but a section of a tape) is bigger than your filesystem so that it
doesn't decide to ask you for a new tape part-way through.
All of the aforementioned are easy enough to resolve with older Exabytes.
Without compression, you know the capacity of the drive and you can dump that
much worth of data in a script and then change tape and dump some more. With
a compressing drive, however, you cannot know the capacity in advance due to
the unpredictability of compression.
The 8505-XL is a 5Gbyte drive which can use the 160M long XL tapes to store 7
Gbytes. These figures are native capacities and the figure of 14 Gbytes
quoted assumes using XL tapes and that you will get compression of 2:1 - very
few real files compress like that - have you 14 Gbytes of ASCII text files ?
Of course, some file types compress even more e.g. sparse databases and some
file types won't compress at all e.g. JPEG images, already compressed files.
I've discussed this with people before and somewhere between 1.4:1 and 1.6:1
is about what people get in the real world. The only REAL way to evaluate
this is to run a script one day while you're there to dump all your file
systems and to see when it fails. Given the amount of data you want to back
up, you might just get it all on one XL tape (if you actually dump near to 10
Gbytes) or else it should all fit handily on two XL tapes (if you actually
dump nearer to 16 Gbytes.
Well, I'm soory to have been so long-winded, but I hope that I've made
matters a little clearer - of course, it wouldn't be unknown for me to have
muddied the waters - if so, please do ask for clarification.
-------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:33 CDT