On Thu, 12 Jun 2003, Jim Sibley wrote:

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


;-)
In one tar command, but not the other, you have specified compression.

I think on the S/390 and zeds I'd leave compression off: it takes too
long in my brandxBoxes.


>
> 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
>

--


Cheers
John.

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

Reply via email to