Can't read SCSI TAPE

Can't read SCSI TAPE

[Masaki Tsuji]

Dear sirs,

Although 'tar' can write to SCSI-TAPE, can't read from.
'tar' reports ....

......
-rw-r--r-- root/root    xxxxx 2001-xx-xx 01:23 usr/bin/xxxxxx
tar: Skipping to next file header                            <------"A"
-rw-r--r-- root/root    xxxxx 2001-xx-xx 01:23 usr/bin/xxxxxxx
......


"A" means written data is wrong, doesn't it???


Thanks for any help.

------------------------------------------
Detailed ->

System...
Kernel : 2.2.11 + raid0145-19990824-2.2.11.gz
          or
         2.2.11
tar    : GNU tar 1.12
mt     : mt-st v. 0.4
glibc2 : glibc-2.0.7pre6

Hardware...
Mother   : Intel Celeron x2 (SMP)
TAPE drv : SONY SDT-9000
TAPE     : DDS1 DDS2 DDS3
SCSI card: AHA-1542
Cable    : SCSI-2 Hi-impeadance , length 0.5m
------------------------------------------

-- 
Masaki Tsuji

Re: Can't read SCSI TAPE

[Richard B. Johnson]

On Wed, 25 Apr 2001, Masaki Tsuji wrote:

> Dear sirs,

Hmmm...

Masaki Tsuji <jammasa@ma.nma.ne.jp>
                      ^^^^^^^^^^^^ ____ This address

... was the address that did the CA-2000-17 attack on one of
our machines a few weeks ago.

This is not an accusation, only an observation. You might
want to tell your network administrator. Sombody at your
site may be hacking systems.

SCSI tape problems or your kind are usually caused by a different
tape compression being used during record and playback. You should
try to use `mt` to set the compression to something you like
before you record, and the same compression when you play back
the tape.

You can use `cat` and `od` to read/write from a tape before you
waste a lot file time with `tar`. You can even do:

		ls >/dev/tape
                 .... takes a lot of time..

		cat /dev/tape  # Read back.

Blocking/deblocking is done in the driver so you can treat it as
a "slow-to-start" FIFO.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).

"Memory is like gasoline. You use it up when you are running. Of
course you get it all back when you reboot..."; Actual explanation
obtained from the Micro$oft help desk.

Re: Can't read SCSI TAPE

[Masaki Tsuji]

Dears,

"Richard B. Johnson" wrote:
> 
> Hmmm...
> 
> Masaki Tsuji <jammasa@ma.nma.ne.jp>
>                       ^^^^^^^^^^^^ ____ This address
> 
> ... was the address that did the CA-2000-17 attack on one of
> our machines a few weeks ago.
> 
> This is not an accusation, only an observation. You might
> want to tell your network administrator. Sombody at your
> site may be hacking systems.

We're very sorry!

Probabry it's 10th or 11th Apr, isn't it?
I was attacked too, but from outside.

I asked my network administrator about that on 13th Apr, and catched reason.
They said that their network equipments had some probrems, and fixed it.


> SCSI tape problems or your kind are usually caused by a different
> tape compression being used during record and playback. You should
> try to use `mt` to set the compression to something you like
> before you record, and the same compression when you play back
> the tape.

I tried compression option, but It doesn't work well.

I tried ...

No.1
# mt datcompression 1
... write
# mt datcompression 1
... read

No.2
# mt datcompression 0
... write
# mt datcompression 1
... read

No.3
# mt datcompression 1
... write
# mt datcompression 0
... read

No.4
# mt datcompression 0
... write
# mt datcompression 0
... read

, but can't

'datcompression' isn't correct option ?


> You can use `cat` and `od` to read/write from a tape before you
> waste a lot file time with `tar`. You can even do:
> 
>                 ls >/dev/tape
>                  .... takes a lot of time..
> 
>                 cat /dev/tape  # Read back.
> 
> Blocking/deblocking is done in the driver so you can treat it as
> a "slow-to-start" FIFO.

I tried, and got error message...

-----------------------------------
# ls >/dev/tape
st0: Write not multiple of tape block size.   <----- ???
ls: write error: Input/output error
#
-----------------------------------
# cat /dev/tape
[inclemental-] Tue Apr 24 03: ......          <----- looks like good!
#
-----------------------------------

Something wrong?



Thanks, for your help.

> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Masaki Tsuji

Re: Can't read SCSI TAPE

[Tim Moore]

> mt     : mt-st v. 0.4

Also mt-st < v0.5b were fairly broken especially with positioning.

rgds,
tim.
--

Re: hundreds of mount --bind mountpoints?

[Alexander Viro]

On 24 Apr 2001, Christoph Rohland wrote:

> Hi Al,
> 
> On Tue, 24 Apr 2001, Alexander Viro wrote:
> >> Half an hour? If it takes more than about 5 minutes for JFFS2 I'd
> >> be very surprised.
> > 
> > <tone polite> What's stopping you? </tone>
> > You _are_ JFFS maintainer, aren't you?
> 
> So is this the start to change all filesystems in 2.4? I am not sure
> we should do that. 

Encapsulation part is definitely worth doing - it cleans the code up
and doesn't change the result of compile. Adding allocation/freeing/
cache initialization/cache removal and chaninging FOOFS_I() definition -
well, it's probably worth to keep such patches around, but whether
to switch any individual filesystem during 2.4 is a policy decision.
Up to maintainer, indeed. Notice that these patches (separate allocation
per se) are going to be within 3-4Kb per filesystem _and_ completely
straightforward.

What I would like to avoid is scenario like

Maintainers of filesystems with large private inodes: Why would we separate
them? We would only waste memory, since the other filesystems stay in ->u
and keep it large.

Maintainers of the rest of filesystems: Since there's no patches that would
take large stuff out of ->u, why would we bother?

So yes, IMO having such patches available _is_ a good thing. And in 2.5
we definitely want them in the tree. If encapsulation part gets there
during 2.4 and separate allocation is available for all of them it will
be easier to do without PITA in process.
								Al

Can't read SCSI TAPE

[Masaki Tsuji]

Dear sirs,

Although 'tar' can write to SCSI-TAPE, can't read from.
'tar' reports ....

......
-rw-r--r-- root/root    xxxxx 2001-xx-xx 01:23 usr/bin/xxxxxx
tar: Skipping to next file header                            <------"A"
-rw-r--r-- root/root    xxxxx 2001-xx-xx 01:23 usr/bin/xxxxxxx
......


"A" means written data is wrong, doesn't it???


Thanks for any help.

------------------------------------------
Detailed ->

System...
Kernel : 2.2.11 + raid0145-19990824-2.2.11.gz
          or
         2.2.11
tar    : GNU tar 1.12
mt     : mt-st v. 0.4
glibc2 : glibc-2.0.7pre6

Hardware...
Mother   : Intel Celeron x2 (SMP)
TAPE drv : SONY SDT-9000
TAPE     : DDS1 DDS2 DDS3
SCSI card: AHA-1542
Cable    : SCSI-2 Hi-impeadance , length 0.5m
------------------------------------------

-- 
Masaki Tsuji