Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory

Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory

[Martin Jacobs]

Hi all,

I cannot read anything from my tape (Tandberg DLT8000, LVD
interface, ID=5) connected to an aic7899 or an sym53c895 using
kernel 2.4.3-XFS or 2.4.7-XFS. (Everything works fine on
2.2.16.) Loading of st.o works. stinit works. mt (status, tape
positioning) works. But when I try to read the amanda header
from the tape (dd if=/dev/nst0m bs=32k count=1) I get the
error

dd: reading `/dev/nst0m': Cannot allocate memory

The syslog says:

Jul 29 17:49:28 depp kernel: sym53c895-0-<5,*>: FAST-10 WIDE SCSI 20.0MB/s (100.0 ns, offset 15)
Jul 29 17:49:28 depp kernel: st0: Block limits 2 - 16777214 bytes.

strace gives something like:

...
open("/dev/nst0m", O_RDONLY|O_LARGEFILE) = 0
...
read(0, 0x8052000, 32768)               = -1 ENOMEM (Cannot
allocate
memory)
...

Nearly the same for tar (with default block size of 512 byte).

BUT: if I use bs=64k it works!!?

TIA

-- 
albrecht jacobs

jangled nerves gmbh
hallstrasse 25
d-70376 stuttgart

fon:   +49 711 550375-44
fax:   +49 711 550375-22

mailto:albrecht.jacobs@janglednerves.com
http://www.janglednerves.com/

Re: Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory

[Kai Makisara]

On Fri, 17 Aug 2001, (Martin Jacobs) wrote:

> Hi all,
>
> I cannot read anything from my tape (Tandberg DLT8000, LVD
> interface, ID=5) connected to an aic7899 or an sym53c895 using
> kernel 2.4.3-XFS or 2.4.7-XFS. (Everything works fine on
> 2.2.16.) Loading of st.o works. stinit works. mt (status, tape
> positioning) works. But when I try to read the amanda header
> from the tape (dd if=/dev/nst0m bs=32k count=1) I get the
> error
>
> dd: reading `/dev/nst0m': Cannot allocate memory
>
...
> Nearly the same for tar (with default block size of 512 byte).
>
> BUT: if I use bs=64k it works!!?
>
In variable block mode in 2.4, you get ENOMEM if the block on the tape is
larger than the byte count in the read(). 2.2 just returned what you asked
for and silentlry threw away the rest of the block. If the byte count is
larger than the block size, then the block is returned.

I.e., the first block on your tape is larger than 32 kB.

	Kai

Re: Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory

[Albrecht Jacobs]

Kai Makisara wrote:
> 
> On Fri, 17 Aug 2001, (Martin Jacobs) wrote:
> 
> > Hi all,
> >
> > I cannot read anything from my tape (Tandberg DLT8000, LVD
> > interface, ID=5) connected to an aic7899 or an sym53c895 using
> > kernel 2.4.3-XFS or 2.4.7-XFS. (Everything works fine on
> > 2.2.16.) Loading of st.o works. stinit works. mt (status, tape
> > positioning) works. But when I try to read the amanda header
> > from the tape (dd if=/dev/nst0m bs=32k count=1) I get the
> > error
> >
> > dd: reading `/dev/nst0m': Cannot allocate memory
> >
> ...
> > Nearly the same for tar (with default block size of 512 byte).
> >
> > BUT: if I use bs=64k it works!!?
> >
> In variable block mode in 2.4, you get ENOMEM if the block on the tape is
> larger than the byte count in the read(). 2.2 just returned what you asked
> for and silentlry threw away the rest of the block. If the byte count is
> larger than the block size, then the block is returned.
> 
> I.e., the first block on your tape is larger than 32 kB.
> 
>         Kai

If I understand you right this is a FEATURE, not a bug! I find it quite
irritating when using a tape device. Shouldn't I get some error message
about wrong block size?
	Forgive me but I am some sort of end user (admin) and not a kernel
hacker.
BTW, where can I get documentation about this 'feature'?
 
Thanks anyway!

-- 
albrecht jacobs

jangled nerves gmbh
hallstrasse 25
d-70376 stuttgart

fon:   +49 711 550375-44
fax:   +49 711 550375-22

mailto:albrecht.jacobs@janglednerves.com
http://www.janglednerves.com/

Re: Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory

[Kai Makisara]

On Sun, 19 Aug 2001, Albrecht Jacobs wrote:

> Kai Makisara wrote:
> >
...
> > In variable block mode in 2.4, you get ENOMEM if the block on the tape is
> > larger than the byte count in the read(). 2.2 just returned what you asked
> > for and silentlry threw away the rest of the block. If the byte count is
> > larger than the block size, then the block is returned.
> >
> > I.e., the first block on your tape is larger than 32 kB.
> >
> >         Kai
>
> If I understand you right this is a FEATURE, not a bug! I find it quite
> irritating when using a tape device. Shouldn't I get some error message
> about wrong block size?

Yes, it is a feature. The behaviour of the Linux driver was changed in
2.4 to match the behaviour of other Unix tape drivers in this case.

It is legal to read blocks that are smaller than the byte count and so
the non-matching block size is not an error as such. It is an error only if
the block is larger than the requested size and this error is returned to
the user. I admit that the code ENOMEM is not too informative but there is
not an error code for too big block size.

> 	Forgive me but I am some sort of end user (admin) and not a kernel
> hacker.
> BTW, where can I get documentation about this 'feature'?
>
It seems that the st man page only documents the 2.2 behaviour (my fault).

I have not seen a good tutorial for tape operations in Unix. The man pages
document some things. The basic rule is that you must know the block
size(s) on the tape and set the parameters accordingly.

	Kai