NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/sgi/16561

Text File | 1992-11-17 | 8.0 KB | 174 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sgigate!sgi!fido!zola!zuni!anchor!olson
From: [e-mail] (Dave Olson)
Subject: Re: more MTIO questions???
Message-ID: <[e-mail]>
Sender: [e-mail] (Net News)
Organization:  Silicon Graphics, Inc.  Mountain View, CA
References: <[e-mail]>
Date: Tue, 17 Nov 92 21:55:00 GMT
Lines: 162

In <[e-mail]> [e-mail] writes:
| on a 440S irix 4.0.1 i have the following questions:
|
| 1) using the 4mm max block size (Maximum block size: 16777215 bytes
|    from mt status) dd returns ENOMEM - Not enough space
|    (the tps man page sez this may be that the kernel mem allocator
|    couldn't allocate it [the jagtape man page doesnt' have this caveat,
|    the ENOSPC comments are quite different too, should they be?] )

16 MB is what the drive supports.  The default maximum DMA size in our
kernel is 4 MB (see /usr/sysgen/master.d/kernel: MAXDMASZ).  Since the
memory has to be locked down during DMA, you don't want to set this too
close to  your physical memory size.

| 2) 4mm when already at EOD
|     a) from my code using regular old read(1) first attempt returns
|        a 0, second read causes "Trace/BPT trap (coredump)"

I've never seen this.  Certainly the tape driver doesn't do it.
Are you *sure* this is happening on the read, and not on something
you are doing right afterwards?

|     b) mt fsr returns ENOSPC (No space left on device)
|     c) dd just sez 0+0 records in out w/ no other diagnostics
|
|    why isn't ENOSPC returned from my read? how should i code the check?

It should be, and is in every case I have ever looked at.

| 3) when reading 4mm from beginning of tape to EOD when last EOF is
|    reached EOF is returned (ok)
|
|    When read after this is issued EOF is returned again
|    (ok, but... it seems to be trying to simulate
|    that it reached a double EOF (logical EOT from 9-track world at
|    least) when it really isn't - i think i like this but i think that
|    8mm tapes on vme/scsi (jag) don't do this (the read after the last
|    EOF returns ENOSPC)

by 'EOF is returned again', do you mean -1, or are you doing an MTIOCGET,
and seeing the FM status bit set?  If the latter, it is a bug.  What should
happen is your read should return -1, with errno set to ENOSPC.

| 4a) is there any speed (or other) advantage to using the fixed block
|    device file over the variable?

Not really for this device.  For some other devices, perhaps.  The
main advantage of using the fixed block device is for devices like 8mm
or 9 track, that have a fairly small max block size with variable block
mode (and therefore limited i/o sizes per request), since in fixed mode,
you can do much larger i/o requests on these drives.

|    i almost always need variable but sometimes if i know its going to
|    be 100% fixed size would i see any increase in throughput

I'd recommend sticking with variable block size on DAT, for portability,
since that seems to be the more common usage (and definitely is on
SGI systems).

|    from the manpages/.h files the only advantage i can find of fixed over
|    variable is that the record size is limited only to physical memory

Well, not quite.  There is still an upper limit (typically 64K or 16M blocks).
That isn't always a memory limitation these days.

| 4b) when in fixed block mode say its set to 1024 like on 8mm and you
|     write 1024*n bytes will the driver lay down IRG's at the 1024 for
|     you?  (i know this works ok for read but never tried for write)

There are no interrrecord gaps for either DAT or 8mm.  They always write
in frames.  8mm has significant capacity lossage for i/o's not a multiple
of 1K (better yet 8K, the track size), but DAT does not.

| 5) is there any more info available on the recommended block size field?
|    the most i can find is in mtio.h where is sez: '"recommended" block size
|    for i/o. Mostly based on compatibility with earlier releases and/or
|    other vendors'

Nope, that's about all there is.  tar uses that size if the 'b' option
isn't given, when writing.

| 6) i'm glad i followed that Usenet thread last month that warned that the
|    jagtape man page TAPE MOVEMENT CRITERIA is incorrect on item #4 where
|    it states that the EOFs will be written only if the last write was not
|    a WEOF (my code showed the same result and i thought i was going crazy)
|
|    anyway, why is it that 8/4mm don't use the double EOF as logical EOT
|    like the 9 tracks?  is it because EOD is so different in helical-scan
|    world? could i get a mini-lecture on it.

Because they have a real EOD marker, 9 track does not.  Therefore 2 FM's
is completely redundant (and on 8mm, although not DAT) wastes a lot of tape
(particularly on the 8200).  The whole reason 9 track drives used 2 FM's
to mark EOD (LEOT is another term for it) was to be able to tell where
the logical end of tape was.  Some 9 track drives also support 'search
for N sequential FM's (N==2 most common), so this LEOT can easily be
found.  All other tape drives I've worked with have an EOD marker
that is enforced by the drive firmware (and is usually searchable
by a special command, except for 8mm).

|    related: what is the action on 9 track, 4/8mm w.r.t. MTEOM and
|    MTAFILE mtop operations?

9 track searches for 2 sequential FM's.  QIC and DAT use 'space to EOD'
commands. 8mm uses a hideous hack of 'space fwd blk; if(!EOD) space wfd FM'
in a loop.  MTAFILE can only be supported on DAT and 9 track, because the
other drives don't allow overwrite.

| 7) i see mtget.mt_fileno and mt_blkno seem to be implemented under tpsc
|    for 4mm - the mtio.h still states that they are not fully implemented
|    i see they are not for kennedy 9-track and jagtape 8mm (are they for
|    tpsc 8mm?)  i hope irix 5.0 has this fully supported, does it?

mt_fileno is not implemented in any SGI tape driver.  It is basicly
impossible, except for a few special cases.  mt_blkno is supported on
drives that return the current blk #.  DAT does support that.  You
can see this with the output from 'mt stat'.  It uses the mt_blkno
field.

| 8) ...and if you haven't totally fallen asleep or hit the delete key yet...
|    when including mtio.h or jagtape.h i have to include types.h first
|    since they use ulong, u_char etc
|
|    is it against ANSI C policy for an include file to include another? (i
|    recall something like this)

Nope.  It is prohibited for files listed in the standard, but for
non-standard files it isn't.  Still, many of us don't like nested
include files.

| 9) is the only way to use mtget and old_mtget (for librmt, /etc/rmt use)
|    to use the rmtops isrmt() function and then pass the correct structure
|    to the ioctl()? (the comments in mtio.h are great!)

You can always pass the mtget struct.  The ioctl code in our rmt library
copies the fields as appropriate if the other side returns the older
structure (as most non-SGI, and old (pre 3.3 IRIX) SGI systems do).

| 10) mt man page references mtio.h, it'ld be nice if the FILES section of the
|    man page referred to it also (ioctl too), but this is icing on the cake

FILES sections very rarely mention include files, as that wasn't the
original intended purpose.  The purpose of the FILES section is to
mention 'files' used at runtime.

|         thanx,   (to dave hopefully; i'll buy ya a brew next time
|               i'm in mountain view!)

I'll never turn down a beer, at least, not a good one!

| p.s. here's to hoping that the new layered drivers will make all the jag/tps
|      driver differences totally moot - unfortunately it looks like irix 5.0
|      for multi-processors won't be around soon enough to cure (some of) my
|      ills

The differences will disappear to the greatest extent possible.
It will be a while before you can get your hands on it; I can't
give any dates, except 'probably calendar year 1993'.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   [e-mail]