[1380] in linux-scsi channel archive
st.o
daemon@ATHENA.MIT.EDU (Floody)
Mon Feb 3 11:22:40 1997
Date: Mon, 3 Feb 1997 11:07:23 -0500 (EST)
From: Floody <flood@evcom.net>
Reply-To: Floody <flood@evcom.net>
To: linux-scsi@vger.rutgers.edu
-----BEGIN PGP SIGNED MESSAGE-----
Greetings!
I'm not sure if this should be addressed to linux-scsi, or perhaps to the
kernel team, but I have a suggestion and comments related to the SCSI tape
driver in kernels 2.0.x and 2.1.x. My apologies if this has already been
discussed.
Background:
I have, for one reason or another, taken it upon myself to attempt to
standardize the way that sequential streaming backup/restore applications
access devices under Linux (applications beyond the scope of low level
utilities such as mt or tar). It is my intention and hope to eventually
have such applications be able to seamlessly interface with *any* type of
standard tape device (regardless of it's hardware interface,
SCSI/IDE/floppy), as well as be able to manipulate remote tape devices on
any Linux box on a network. Phase 1 of this project involves sorting out
the current application->driver interface and using rmt for remote device
access. Phase 2 (which I have not yet started) will involve extending and
altering the rmt protocol to be device and platform independant. Once
I have completed the protocol and implementation, I will lsm, distribute
and attempt to communicate with various application developers in order to
have support implemented.
Problem:
In the course of this project I have examined several applications, kernel
drivers and assorted third party patches. The problem I have encountered
with the application interface for tape devices is one of block sizes
(setting & getting). For tape applications, block sizes are extremely
important. If an application is not able to determine the current media's
block size (or set it to user specification, for new tapes) it can
represent a significant problem (unable to CRC block check, fast forward
using block counts, etc). If the end user *knows* the block size, they
can simply force the application to use the given block size to get around
this, however is is quite conceivable that a situation might arise where
block sizes are _not_ known.
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.
IDE - The kernel ide tape driver emulates SCSI, although it appears that
the block size can't be set (via MTIOCTOP), only read. While not prefect,
this at least allows tape applications to determine the block size of
unknown tapes; significantly extending their abilities.
ftape/sftape - The floppy tape driver (including the latest version) does
NOT have the capability to set *or* get block sizes. This, IMO, is a very
serious limitation. Fortunately, ftape + sftape/zftape have been merged,
and will hopefully be integrated into newer kernels. I am recommending
that floppy tape users _always_ use zftape (as opposed to sftape) as the
front end interface to ftape.
zftape - The latest version (older versions too, perhaps) supports setting
the block size via the well documented MTIOCTOP ioctl. Media block size
read operation is accomplished via a new read ioctl: MTIOCVOLINFO. Not
only does this return block size, it also provides some other pieces of
potentially highly useful information (media size, compression, etc).
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 */
As you can see, it's quite possible that *none* of the structure members,
aside from mt_blksz, can be supported under SCSI at this time. However,
standardizing now extends the capabilities of media information retrieval,
and allows for possible extension of the SCSI tape driver in the future.
+-------------------------------------------------------------------+
+ -- Finger: flood@evcom.net for my PGP public key -- +
+-------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMvYNPRsjWkWelde9AQGuJwQAoB6dhEndHrgi13sqtJEw0SHtwuw2OAnh
GRo0+gYKliAcdBYqgqHOGKJOZAQEbWVFJzelfuaEMUKpgSYCLVQB4caBA8q07trw
1veDVo5pE1UDVJSbNNJLVg3DzjSGyrw7qnjdRM1QAiLMuqm564Vu6cnDGAwEpOhJ
oNHSbYvjtGs=
=t/Ss
-----END PGP SIGNATURE-----
