[1383] in linux-scsi channel archive
Re: st.o
daemon@ATHENA.MIT.EDU (Floody)
Mon Feb 3 16:53:33 1997
Date: Mon, 3 Feb 1997 16:03:06 -0500 (EST)
From: Floody <flood@evcom.net>
To: Kai.Makisara@metla.fi
cc: linux-scsi@vger.rutgers.edu
-----BEGIN PGP SIGNED MESSAGE-----
On Mon, 3 Feb 1997, Kai M{kisara wrote:
> On Mon, 3 Feb 1997, Floody wrote:
> ...
> > Details:
> >
> > Determining and setting block size is accomplished in a variety of
> > different manners, dependant on the device driver being used.
> >
> > SCSI - The MTIOCGET ioctl() is used to retrieve block size. The block
> > size is returned in the *device dependant* status member of the mtget data
> > structure. This has the advantage of being quite standardized, and also
> > working with rmt (assuming that the rmt protocol itself doesn't cause
> > problems, which is *not* a good assumption, but that's phase 2 of my
> > project). MTIOCTOP is used to set the block size for the current media.
> >
> The MTIOCGET ioctl returns the block size the drive reports. It is not the
> best possible way to get the block size. Some drives don't recognize the
> block size before the tape is being read. If the drive is in variable
> block mode, block size zero is reported.
>
> A quite good way to find out the block size is to set the drive to
> variable block mode, try to read a large block, and see what you get. This
> does not need any additional kernel support.
I assume by this that you mean attempting to set the block size to 0, and
then performing a large read?
> ...
> > SCSI Suggestion:
> >
> > Using MTIOCTOP to set media block size seems intuitive, well documented
> > and reasonable. However, in the interest of future standardization, I
> > recommend that an additional ioctl be added into the SCSI tape driver for
> > the purposes of determining media volume information. While it may not be
> > possible to retrieve _all_ of the information (dependant on the physical
> > device's capabilities), certainly _some_ of the information can be
> > retrieved, and the rest set to a null (meaningless) value. Again, in the
> > interests of standardization, I recommend that MTIOCVOLINFO, already
> > introduced by the popular zftape driver, be implemented in the SCSI tape
> > driver. Specifically (for those of you who don't have zftape):
> >
> > struct mtvolinfo {
> > int mt_volno; /* vol-number */
> > unsigned long mt_blksz; /* blocksize */
> > unsigned long mt_rawsize; /* raw tape space consumed */
> > unsigned long mt_size; /* volume size after decompression */
> > int mt_cmpr; /* this volume compressed? */
> > };
> >
> > #define MTIOCVOLINFO _IOR('m', 8, struct mtvolinfo) /* info about volume */
> >
> This ioctl is specific to Linux and may not be the best possible for all
> of the tape types. As you say, it does not give any new information about
> SCSI tapes.
>
> Instead of making a new ioctl (which adds kernel code), why not make a
> tape access library that uses the existing interfaces. The library could
> support also other Unices (and maybe other operating systems, too) and
> this would make the tape access library much more useful for programs than
> a method that works only in Linux.
That is indeed an interesting idea. I would be willing to write the
initial version of this library, which would include full SCSI support and
minimal IDE/ftape/zftape if some other coder with access to one of the
non-SCSI interfaces would be willing to test and flush out any pieces that
are missing. I don't have access to non-SCSI hardware.
> If you generalize rmt so that ioctls can be reliably used in heterogenous
> environment, that would be very welcome :-)
>
> Kai
>
Yes, my plan is to implement mostly high level calls, all returning
non-binary system independant information. There will also be lower level
ioctl calls, but binary data will be translated into something portable
(probably an ascii hex attribute table) before being transmitted to the
client. It will also be completely downward compatible with the old rmt.
+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMvZSjBsjWkWelde9AQFLVwP/RaaVXg0nhilBL+v4RDbmFNXKF9spDoaz
aj3tWSd2E2wZdDIO0VqtkJAEXdisatViM/WYDI1AHWzuf2zqggnT+yhTOLZWEFME
bmXwlIORT4qLUk0gpEZ3/uM2Q02JrKEMW9UJTEXoNm/9/LiS1fXUJruX+lW5l2gE
E4L2hiU7KxE=
=mA21
-----END PGP SIGNATURE-----
