David Boyes wrote:
On the other hand, if you're talking about networking over shared memory
-- which is really what a guest LAN is -- then the amount of latency is
so much smaller than the latency of the tape write that the *tape* is
the bottleneck, not the comm link...8-)
I wasn't really talking about the latency, but of the overhead of
breaking data down and put it in packets, with header info, etc,
transmitting thru/to another process which reads the header, reconstruct
the data just to turn around it write it to tape.
Right? Write to tape is still faster than to transmit to another
process to write to the same tape?
Like I said, I'm old. Still think that any resources I don't use are
available to the users (who actually end up paying the bill, or at least
justify our existence).
(one reason that you also want to give the guest running the Amanda
server a lot of scratch disk space -- the network adapters are so fast
in this environment that you'll need to spool to disk and then to tape
to allow the server to keep up without eating the entire processor).
I currently have a process for the last few years, that effectively
attach/detach large pools of disk space between Linux images. For some
things, I just need scratch disk space, for other things, my RPM
repository. So this has never been a big deal.
One of the beautifal things about virtualization: just define a new LAN
segment, connect the machines that need to communicate. No collisions
with production...8-)
Still communications. But I do see the point. I'm on z/VM 4.2 so I
have guest lan support, but not all the features that are on later releases.
If you have a choice, use Bacula. Amanda is super-portable, but really
relies on ever increasing tape sizes to compete with the exponential
growth of disk storage. Bacula does a much better job handling datasets
that span multiple tapes.
I got lots of choices, I think. Just trying each one and evaluating
which meets me needs. So for, nothing does everything.
Right now, I use DDR for disaster type recovery and tar for logical
restores. I ftp the resulting "listing" from tar, of all files backed
up along with a directory listing of the entire system, to CMS so I have
some information on what could be restored, if needed.
So far, I've just had to restore some files from /home.
TSM initially sounded good, but it required scsi attached tape drives
(i.e. FCP attached), and at this point, I don't want to have separate
FICON and FCP attached tape drives. Right now, due to cost
and I don't
perceive the need. In a year or two, that may change.
No, it's just a silly "feature". There is no technical reason for TSM
not to use channel-attached drives, and good business reasons for it to
do so (like people already OWN them...), but that's fallen on deaf ears.
Time to build a better mousetrap.
Bad part about this, is the IBM Business Partners seem to only talk TSM
when trying to sell z/890s and z/Linux. So sometimes they can steer the
extra hardware as being just a given. So, you pay the BP to steer to
FCP, instead of paying developers to provide for channel attached tape
drives.
I do see that FCP devices are more efficient. They have less overhead
in the controller (making the devices look like mainframe devices) and
in Linux, (making mainframe devices look like PC type stuff).
And later, it may be worth wild to buy FCP adapters to supplement the
FICON adapters and to duplicate/dedicate 3590 hardware, but not when we
are just starting (and perhaps being a gamble on all of this actually
working).
Tom Duerbusch
THD Consulting
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
