|
Re: [Networker] Block size for LTO-3 drives
2007-03-16 06:54:48
George Sinclair wrote:
We recently added four LTO-3 drives to our tape library, and we still
have two older LTO-1 drives in there, too.
I played around with loading and recovering some data from an older
LTO-1 tape in all of 6 drives. No problems.
One thing I notice is that NetWorker used to report a Volume block
size of 64 KB for this field
(nwadmin->Media->Devices) once an LTO-1 tape was loaded in one of the
LTO-1 drives and
continued to report that as the block size for the given device ever
after. Now, I notice that it reports 128 KB for the new
LTO-3 drives until I load an older LTO-1 tape in which case it changes
to 64 KB, and then after
ejecting the tape, it reports 128 KB again for the device. For the
older LTO-1 drives, it remains at 64 KB.
I've not labeled an LTO-3 tape yet in the new LTO-3 drives, but I
suspect it will report those as 128 KB.
Our SDLT drives always reported 128 KB - both the newer SDLT-600
drives and the older SDLT-220 drives.
I always thought it was interesting that NetWorker used this higher
block size on the SDLT drives but only
half that on the LTO-1 drives. Now, it appears that the LTO-3s are
getting a better shake? Anybody know the
scoop on this? Will this make reads and writes faster and more
efficient? Is there some reason it was set to
64 KB for LTO-1? Can this be changed or should it be?
I've never mucked around with it but just asking. We've always
declared blocksize=0 in our /etc/stinit.def file for all drive
definitions which I thought was what NetWorker liked and allowed for
variable block size. Hmm ...
George,
In theory there will be an optimum block size for different devices in
each environment. You could do tests to see which block size works best
for you, but to be honest I doubt that it is worth the trouble. In the
past I ran tests on LTO-1 drives in a SAN environment and found that
128KB or 256KB was slightly better than the NetWorker default of 64KB,
but this may have been due to the latency caused by having a SAN involved.
It is interesting to note that Legato/EMC have chosen 128KB for LTO-3,
after sticking with 64KB for LTO-1 and LTO-2, although I don't think
there is a great deal of science behind these decisions. As an example
the DLT7000 was defined as a 128KB block size, whereas the DEC TZ89
(same physical device) was defined as 96KB - explain that.
In many environments it is more convenient to have a standard 64KB block
size for interoperability purposes. If you mix Unix and Windows storage
nodes you will find that many Windows SCSI cards or fibre HBAs will have
a limit of 64KB block size in their drivers. This can be changed by
changing registry settings in many (not all) cases but it is a
considerable hassle to do so.
If you really need to wring the last bit of performance from your
drives, then go ahead and find the optimum block size for each drive
type in your environment, this is of course assuming that you don't
already have some other bottleneck in your network or disk subsystems.
If you want an easy life, just leave things as they are, since these new
LTO-2 and LTO-3 drives are already so damn fast.
Declaring blocksize=0 (variable) in your stinit.def is correct.
NetWorker defines the block size at a higher level and would not be able
to correctly do this if you misconfigured your stinit.def.
Davina.
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
|
|
