Accessing Tape Drive on another linux system

[Mike McCarty]

amar_padhi wrote:
> Hi,
> requirement is simple. Two servers exist on RHEL 3.0. The tape drive is

This requirement is not simple.

> connected to server B. The databases are on server A. We want a direct
> access to the tape drive on server B from server A. This way we will be
> able to do online backups direct to the server B tape drive from server
> A databases. Redhat support informed that this is not possible, i.e.,
> tape drives cannot be shared across the network.
> 
> I am very sure this is possible. This is a requirement which every
> multi-server organization will have and linux is more than capable of
> doing this!

Actually, it doesn't make sense. The issue is one of how tape drives
work. They work in one of two modes: start/stop or streaming. Generally,
one wants to use streaming mode because it is *much* faster, and most
drivers try to support this. The only problem is that the stream *must*
*not* be interrupted, or the write will fail, and one must start all
over. This implies that you must have predictable delays in data
arrival, which generally precludes network access. Even with start/stop
mode, a tape is a *non sharable* device. Device ownership over a network
is a non-trivial matter to manage.

> Do provide your inputs. Bottom line, how do I share my tape drive on the
> network (for linux servers only).

Tape drives are non-sharable by their very nature. This is not
a Linux issue per se. Allowing more than one process to read/write
a tape is not reasonable, due to the nature of the medium. Assigning
ownership over a network is not really manageable. The usual
way to do this is to create a special application with client/server
architecture, and let the server part manage the tape and ownership
of access. Even then, things are pretty hairy. Normally, some sort
of "heartbeat" to (1) verify connectivity, (2) verify that the other end
is "alive", and (3) timeout/closure upon failure is necessary. In
extreme cases, recovery of the connection is also required.

I speak from experience having a background in telephony where
Call Detail Records *must* be written to tape, or $$$ gets lost,
in an environment where a multiprocessor switch interconnected via
a message interface was used (not ethernet, but similar in concept).

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!