John, please elucidate. Is the discussion incorrect or did I code the tar
coding example incomplete? If so, what would you have coded?

Regards, Jim
Linux S/390-zSeries Support, SEEL, IBM Silicon Valley Labs
t/l 543-4021, 408-463-4021, [EMAIL PROTECTED]
*** Grace Happens ***




                      John Summerfield
                      <[EMAIL PROTECTED]        To:       [EMAIL PROTECTED]
                      afe.com.au>                  cc:
                      Sent by: Linux on 390        Subject:  Re: Linux390 + VM + Tape 
3490
                      Port
                      <[EMAIL PROTECTED]
                      EDU>


                      06/12/2003 03:26 PM
                      Please respond to
                      Linux on 390 Port






On Thu, 12 Jun 2003, Jim Sibley wrote:

> >File open-to-close doesn't
> >sound like a very useful paradigm (but I don't know how Linux
applications
> >use tape drives) and I don't know if one part of Linux can open a tape
> >file (tape management system, just to lock the drive and to request a
tape
> >mount) and another part of Linux subsequently
> >opening-writing/reading-closing the same tape so that the drive is not
> >unassigned until the tape management system closes the tape file.
>
> The implementation is what you would expect for a shared printer, a write
> only device - during write, the device is dedicated and after the write,
> the "data" is no longer available.
>
> The assign is done at open/close time, I suspect if one applicaiton
assigns
> the drive and leaves it assigned, then another application uses the
drive,
> then the the assign would be dropped after the second app closes the
file.
>
> As implemented, is dangerous for shared tape, as it does not allow time
for
> operator intervention (loading/unloading the tape) before it is used by
> another hosts, and 2) two hosts could rewind and/or record to the same
tape
> without knowing it.
>
> For example, tar is an applicaiton that can write to the tape directly
and
> read it back.
>
>       tar -cvpi -f /dev/ntibm0
>
>       some time later   (during this time, another system could do a
> similar function)
>
>       tar -xzpi  -f /dev/ntibm0     results could be unpredictable or you
> might get someone elses data!

That will _never_ work, even without another macine stuffing you up!!





--


Cheers
John.

Join the "Linux Support by Small Businesses" list at
http://mail.computerdatasafe.com.au/mailman/listinfo/lssb

Reply via email to