[581] in linux-scsi channel archive
Re: st.c driver errors can get lost!
daemon@ATHENA.MIT.EDU (Kai Makisara)
Sat Sep 2 07:41:59 1995
Date: Sat, 2 Sep 1995 10:12:16 +0300 (EET DST)
From: Kai Makisara <makisara@abies.metla.fi>
Reply-To: Kai.Makisara@metla.fi
To: Richard Waltham <dormouse@farsrobt.demon.co.uk>
Cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <199509010037.BAA08804@farsrobt.demon.co.uk>
On Fri, 1 Sep 1995, Richard Waltham wrote:
>
> Over the last few weeks I've been developing a scsi peripheral that looks
> like a multiple lun tape device and I've been using Linux to test it.
>
...
>
> I have patched my st.c driver to put the lun into the first byte of the
> CDB as done in the sd.c driver and I can now successfully access tape
> devices on seperate lun's. Should I submit patches for inclusion in the
> official linux releases? Who to? Any one else interested in seeing them?
> Should I post the patches here?
>
One possibility is to send the patches to me. I have one small fix to
send to Linus anyway (some ioctls are not allowed with write protected
tape in the drive; they should only be forbidden if the user has no write
permission).
...
> 3. A much more serious problem is that in certain circumstances it appears
> possible to loose errors reported by a scsi tape device during writing.
...
> The standard kernel distributions have the st.c driver set up to write
> asynchronously. Write errors are checked for at the start of the next write
> command when any errors in the last write are reported. If the tar is only
> one block long, in unbuffered variable block mode, or several/many blocks
> long in buffered mode, the error is not detected until the close (device
> release?) and the device close routine does not return an error. Also the
> closing filemark(s) is written during the close routine so if there is an
> error during writing the filemark this is also not reported other than by
> another short message in /var/adm/messages. Looking at another driver it
> appears that release does not return any value. Is that correct? If so is
^^^^^^^
I have been aware of this problem and the reason is, as you have noticed,
that the there is no other way for the close function to return an error
than to log it. The release function is defined in include/linux/fs.h as
follows:
struct file_operations {
int (*lseek) (struct inode *, struct file *, off_t, int);
int (*read) (struct inode *, struct file *, char *, int);
int (*write) (struct inode *, struct file *, const char *, int);
int (*readdir) (struct inode *, struct file *, void *, filldir_t);
int (*select) (struct inode *, struct file *, int, select_table *);
int (*ioctl) (struct inode *, struct file *, unsigned int,
unsigned long);
int (*mmap) (struct inode *, struct file *, struct vm_area_struct *);
int (*open) (struct inode *, struct file *);
void (*release) (struct inode *, struct file *);
int (*fsync) (struct inode *, struct file *);
int (*fasync) (struct inode *, struct file *, int);
int (*check_media_change) (dev_t dev);
int (*revalidate) (dev_t dev);
};
> there any way round this or do we have to live with it?
>
As you note in your message, if you want utmost reliability in backups, you
should disable asynchronous writes and write buffering (you don't have to
recompile the kernel; just use the MTSTOPTIONS ioctl). Another possible
problem with some programs is that async writes delay reporting errors
and the program may not handle this correctly (it does not
"know" that it was actually some earlier write that failed).
On the other hand, async writes have a positive effect on performance in
some systems. How to balance these factors is up to each individual user.
...
> Thanks for reading all the way to the end - you did didn't you? :-)
Yes :-)
> Richard
>
Kai
* Kai Makisara * email Kai.Makisara@metla.fi *
| Finnish Forest Research Institute | tel. +358-0-857 05 334 |
| Unioninkatu 40A | fax +358-0-625 308 |
* FIN-00170 Helsinki, Finland * GSM +358-40-5533211 *
