[lkml]   [2001]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Q: 2.4.[37]-XFS: /dev/nst0m: cannot allocate memory
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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:57    [W:0.032 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site