From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Jul 2 00:14:41 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id AAA19910 for ; Thu, 2 Jul 1998 00:14:38 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id AAA06406 for ; Thu, 2 Jul 1998 00:14:34 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id AAA07497 for ; Thu, 2 Jul 1998 00:13:19 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id AAA15716; Thu, 2 Jul 1998 00:12:36 +0200 Received: by vger.rutgers.edu id <970960-988>; Wed, 1 Jul 1998 17:25:37 -0400 Received: from [207.109.249.50] ([207.109.249.50]:10328 "EHLO Stimpy.netroedge.com" ident: "root") by vger.rutgers.edu with ESMTP id <971051-988>; Wed, 1 Jul 1998 17:12:21 -0400 Received: from localhost (phil@localhost) by Stimpy.netroedge.com (8.8.7/8.8.7) with SMTP id NAA15791; Wed, 1 Jul 1998 13:31:27 -0700 Date: Wed, 1 Jul 1998 13:31:27 -0700 (PDT) From: phil@Stimpy.netroedge.com Reply-To: phil@Stimpy.netroedge.com To: Kai.Makisara@metla.fi cc: linux-kernel@vger.rutgers.edu Subject: Re: Tape drive use under Linux In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO On Wed, 1 Jul 1998, Kai M{kisara wrote: > On Wed, 1 Jul 1998 phil@Stimpy.netroedge.com wrote: > > > > Does anyone know how Linux treats tape formats using things like tar and > > mt? In other words, if a tape isn't formatted, how does one format it so > > I don't get I/O errors when using tar? > > > You don't usually have to format the tapes in modern drives. However, I > don't have any experience on AIT but the other helical scan tapes don't > need formatting. I remember vaguely reading that tapes usually come formatted, but some brands need to be formatted on a Win box before use on a Linux box. > Do you see any messages related to the problem in the system logs? I forgot to include that! Here's what it says: Jul 1 04:25:45 Teller kernel: st0: Error with sense data: Current error st09:00: sense key Medium Error Jul 1 04:25:45 Teller kernel: Additional sense indicates Write error Jul 1 04:25:45 Teller kernel: st0: Error with sense data: Current error st09:00: sense key Medium Error Jul 1 04:25:45 Teller kernel: Additional sense indicates Write error Jul 1 04:25:45 Teller kernel: st0: Error on write filemark. Jul 1 04:26:59 Teller kernel: st0: Error with sense data: extra data not valid Current error st09:00: sense key Medium Error Jul 1 04:26:59 Teller kernel: Additional sense indicates Write error It definitely indicates a medium error, which is why I figured the tape got 'corrupted' at that spot on the tape from previous driver/bios/kernel mis-configurations which resulted in other errors before I fixed it (at least I'm pretty sure I fixed it :'). > The > driver prints some information there. If you '#define DEBUG 1' in > linux/drivers/scsi/st.c and recompile the kernel, you get some more > information. I may try that. Thanks! Phil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Jul 2 08:20:36 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id IAA23172 for ; Thu, 2 Jul 1998 08:20:35 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id IAA09804 for ; Thu, 2 Jul 1998 08:20:31 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id IAA24134 for ; Thu, 2 Jul 1998 08:19:16 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id IAA17817; Thu, 2 Jul 1998 08:18:22 +0200 Received: by vger.rutgers.edu id <970886-988>; Thu, 2 Jul 1998 01:28:16 -0400 Received: from ns.imp.ch ([157.161.1.2]:1614 "EHLO mail.imp.ch" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <970885-988>; Thu, 2 Jul 1998 01:27:20 -0400 Received: from impch.imp.ch (impch.imp.ch [157.161.1.1]) by mail.imp.ch (8.8.8/8.8.5) with SMTP id IAA21179 for ; Thu, 2 Jul 1998 08:12:09 +0200 (MET DST) Received: by impch.imp.ch with UUCP (5.65b/IDA-052490) id AA28496; Thu, 2 Jul 98 06:12:07 GMT Received: (from news@localhost) by vulcan.alphanet.ch (8.8.5/8.7.3) id HAA23372 for linux-kernel@vger.rutgers.edu; Thu, 2 Jul 1998 07:26:37 +0200 Path: alphanet.ch!not-for-mail From: Marc SCHAEFER Newsgroups: alphanet.ml.linux.kernel Subject: Re: Tape drive use under Linux Date: 2 Jul 1998 07:26:36 +0200 Organization: ALPHANET NF -- Not for profit telecom research Lines: 28 Distribution: alphanet Message-Id: <6nf5mc$mq4$1@vulcan.alphanet.ch> References: <6ndv79$bmm$1@vulcan.alphanet.ch> Nntp-Posting-Host: vulcan.alphanet.ch X-Newsreader: TIN [UNIX 1.3 unoff BETA 970705; i586 Linux 2.0.27] Xref: alphanet.ch alphanet.ml.linux.kernel:27440 Apparently-To: linux-kernel@vger.rutgers.edu To: unlisted-recipients:; (no To-header on input) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO phil@Stimpy.netroedge.com wrote: > Does anyone know how Linux treats tape formats using things like tar and > mt? In other words, if a tape isn't formatted, how does one format it so > I don't get I/O errors when using tar? On the SONY SDT-7000 and SDX-3xx, I always do something like: mt -f /dev/st0 setblk 0 find . -print | cpio -o --io-size=32768 -O /dev/st0 -H crc You can also specify the block size with tar I think. When doing network backups, I do: find . -print | cpio -o --io-size=32768 -H crc | rsh some-server -l some-user \(mt -f /dev/st0 setblk 0 \; dd of=/dev/st0 bs=32768 \) > been using for nightly back-ups. Well, my SCSI driver got misconfigured > or something and corrupted a few tapes. I've fixed that, but now some of > the tapes don't work at all anymore. Each time I try to use one, it says: maybe wrong block size ? > Is there a Linux utility which can re-format the tapes for me? (And, don't > say "mt -f /dev/st0 erase" because that doesn't seem work.) Do I need to > move the tape-drive to a Windows machine and format the tapes there? I never had to re-format any DAT tape. I don't know how to do it anyway. Ok, this is AIT. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu From owner-linux-kernel-outgoing@vger.rutgers.edu Mon Jul 13 18:49:18 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA04091 for ; Mon, 13 Jul 1998 18:49:18 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA18020 for ; Mon, 13 Jul 1998 18:49:17 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id SAA15239 for ; Mon, 13 Jul 1998 18:48:23 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id SAA28883; Mon, 13 Jul 1998 18:47:40 +0200 Received: by vger.rutgers.edu id <971875-26836>; Mon, 13 Jul 1998 11:32:28 -0400 Received: from tiktok.cygnus.com ([192.80.44.20]:2239 "EHLO tiktok.cygnus.com" ident: "meissner") by vger.rutgers.edu with ESMTP id <971894-26836>; Mon, 13 Jul 1998 11:31:28 -0400 Received: (from meissner@localhost) by tiktok.cygnus.com (8.8.7/8.8.5) id MAA20302; Mon, 13 Jul 1998 12:43:08 -0400 Date: Mon, 13 Jul 1998 12:43:08 -0400 Message-Id: <199807131643.MAA20302@tiktok.cygnus.com> From: Michael Meissner To: ncr53c810@Colorado.edu, linux-kernel@vger.rutgers.edu Subject: TAPE problems with 3.0e of Linux NCR538XX SCSI drivers X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO I have a dual pentium Pro machine with 2 SCSI controllers (one TekRam 390U that has a DAT tape drive on it and a CDROM, and the other TekRam 390F that has 2 narrow barracudas and 1 wide barracuda on it), running RedHat 5.1 with updates. I upgraded the linux kernel 1.0.5 (with the 2.5f version of the SCSI drivers for NCR53C8XX) to 1.0.8 (version 3.0e of the SCSI drivers) with the Alan Cox patches applied. Whenever my nightly scripts try to do a dump, they first do a: st -f /dev/nst0 rewind The SCSI controller spits out the following message to the syslog: Jul 12 03:04:11 tiktok kernel: SCSI host 0 abort (pid 34805) timed out - resetting Jul 12 03:04:11 tiktok kernel: SCSI bus is being reset for host 0 channel 0. Jul 12 03:04:11 tiktok kernel: ncr53c8xx_reset: pid=34805 reset_flags=2 serial_number=382045 serial_number_at_timeout=382045 Jul 12 03:04:11 tiktok kernel: ncr53c875-0: restart (scsi reset). Jul 12 03:04:11 tiktok kernel: ncr53c875-0: Downloading SCSI SCRIPTS. Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,0>: phase change 6-7 6@0764acc8 resid=4. Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,*>: asynchronous. and then the mt process hangs (which of course hangs the rest of the dump script). -- Michael Meissner, Cygnus Solutions (Massachusetts office) 4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Mon Jul 13 20:26:57 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id UAA05173 for ; Mon, 13 Jul 1998 20:26:56 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id UAA18786 for ; Mon, 13 Jul 1998 20:26:56 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id UAA17773 for ; Mon, 13 Jul 1998 20:26:02 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id UAA29441; Mon, 13 Jul 1998 20:22:25 +0200 Received: by vger.rutgers.edu id <971961-26836>; Mon, 13 Jul 1998 13:06:08 -0400 Received: from ppp-98-249.villette.club-internet.fr ([194.158.98.249]:1211 "EHLO localhost.localdomain" ident: "groudier") by vger.rutgers.edu with ESMTP id <971958-26836>; Mon, 13 Jul 1998 13:05:47 -0400 Received: from localhost (groudier@localhost) by localhost.localdomain (8.8.4/8.8.4) with SMTP id TAA02077; Mon, 13 Jul 1998 19:19:31 +0200 X-Authentication-Warning: localhost.localdomain: groudier owned process doing -bs Date: Mon, 13 Jul 1998 19:19:31 +0200 (MET DST) From: Gerard Roudier X-Sender: groudier@localhost To: Michael Meissner cc: ncr53c810@Colorado.edu, linux-kernel@vger.rutgers.edu Subject: Re: TAPE problems with 3.0e of Linux NCR538XX SCSI drivers In-Reply-To: <199807131643.MAA20302@tiktok.cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO On Mon, 13 Jul 1998, Michael Meissner wrote: > I have a dual pentium Pro machine with 2 SCSI controllers (one TekRam > 390U that has a DAT tape drive on it and a CDROM, and the other TekRam > 390F that has 2 narrow barracudas and 1 wide barracuda on it), running > RedHat 5.1 with updates. I upgraded the linux kernel 1.0.5 (with the > 2.5f version of the SCSI drivers for NCR53C8XX) to 1.0.8 (version 3.0e > of the SCSI drivers) with the Alan Cox patches applied. Whenever my > nightly scripts try to do a dump, they first do a: > > st -f /dev/nst0 rewind > > The SCSI controller spits out the following message to the syslog: > > Jul 12 03:04:11 tiktok kernel: SCSI host 0 abort (pid 34805) timed out - resetting The SCSI tape driver timeout is by default 900 seconds. Is it enough to rewind the tape ? (I guess yes). Driver 3.0e reads the NVRAM by default. If you did'nt enable this feature in 2.1.105, then the NVRAM setup may have changed the device configuration assumed by the driver. The driver will ignore the NVRAM if you enter the following option at boot up. ncr53c8xx=nvram:n Could you check that the controller setup in the NVRAM has SCSI disconnection enabled for all devices. > Jul 12 03:04:11 tiktok kernel: SCSI bus is being reset for host 0 channel 0. > Jul 12 03:04:11 tiktok kernel: ncr53c8xx_reset: pid=34805 reset_flags=2 serial_number=382045 serial_number_at_timeout=382045 > Jul 12 03:04:11 tiktok kernel: ncr53c875-0: restart (scsi reset). > Jul 12 03:04:11 tiktok kernel: ncr53c875-0: Downloading SCSI SCRIPTS. > Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,0>: phase change 6-7 6@0764acc8 resid=4. This is another story. Target 2 (DAT?) seems to dislike the negotiation message after the reset without having actually read it. Could be in some initialization process since the timestamps indicates that there is no delay between the SCSI reset and the next command. > Jul 12 03:04:11 tiktok kernel: ncr53c875-0-<2,*>: asynchronous. > > and then the mt process hangs (which of course hangs the rest of the > dump script). Could you send me the kernel messages printed out at boot-up and _all_ the messages printed by the SCSI layer when the problem occured. Regards, Gerard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Jul 14 03:32:59 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id DAA08336 for ; Tue, 14 Jul 1998 03:32:57 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id DAA20805 for ; Tue, 14 Jul 1998 03:32:55 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id DAA26208 for ; Tue, 14 Jul 1998 03:32:01 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id DAA32530; Tue, 14 Jul 1998 03:28:24 +0200 Received: by vger.rutgers.edu id <971778-26836>; Mon, 13 Jul 1998 20:11:07 -0400 Received: from tiktok.cygnus.com ([192.80.44.20]:1030 "EHLO tiktok.cygnus.com" ident: "meissner") by vger.rutgers.edu with ESMTP id <971983-26836>; Mon, 13 Jul 1998 20:00:21 -0400 Received: (from meissner@localhost) by tiktok.cygnus.com (8.8.7/8.8.5) id VAA05477; Mon, 13 Jul 1998 21:12:52 -0400 Date: Mon, 13 Jul 1998 21:12:52 -0400 From: Michael Meissner Message-Id: <199807140112.VAA05477@tiktok.cygnus.com> To: groudier@club-internet.fr, meissner@cygnus.com Subject: Re: TAPE problems with 3.0e of Linux NCR538XX SCSI drivers Cc: linux-kernel@vger.rutgers.edu, ncr53c810@Colorado.edu X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO | On Mon, 13 Jul 1998, Michael Meissner wrote: | | > I have a dual pentium Pro machine with 2 SCSI controllers (one TekRam | > 390U that has a DAT tape drive on it and a CDROM, and the other TekRam | > 390F that has 2 narrow barracudas and 1 wide barracuda on it), running | > RedHat 5.1 with updates. I upgraded the linux kernel 1.0.5 (with the | > 2.5f version of the SCSI drivers for NCR53C8XX) to 1.0.8 (version 3.0e | > of the SCSI drivers) with the Alan Cox patches applied. Whenever my | > nightly scripts try to do a dump, they first do a: | > | > st -f /dev/nst0 rewind | > | > The SCSI controller spits out the following message to the syslog: | > | > Jul 12 03:04:11 tiktok kernel: SCSI host 0 abort (pid 34805) timed out - resetting | | The SCSI tape driver timeout is by default 900 seconds. | Is it enough to rewind the tape ? (I guess yes). | Driver 3.0e reads the NVRAM by default. If you did'nt enable this | feature in 2.1.105, then the NVRAM setup may have changed the | device configuration assumed by the driver. The driver will ignore | the NVRAM if you enter the following option at boot up. | ncr53c8xx=nvram:n | Could you check that the controller setup in the NVRAM has SCSI | disconnection enabled for all devices. I did enable the feature. However further testing shows something else, presumably hardware problems is going on. I can't access the driver via either 2.5f of the NCR53C8XX drivers or the Adaptec 2940UW driver (both of these previously worked with the drive, and I didn't do any hardware hacking). So now the problem is who fixes DAT drives, and what do they charge :-( Thanks for the help. -- Michael Meissner, Cygnus Solutions (Massachusetts office) 4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Jul 14 23:20:54 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id XAA04211 for ; Tue, 14 Jul 1998 23:20:50 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id XAA06703 for ; Tue, 14 Jul 1998 23:22:00 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id XAA04555 for ; Tue, 14 Jul 1998 23:20:43 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id XAA05005; Tue, 14 Jul 1998 23:17:04 +0200 Received: by vger.rutgers.edu id <971141-1094>; Tue, 14 Jul 1998 16:00:59 -0400 Received: from tiktok.cygnus.com ([192.80.44.20]:1417 "EHLO tiktok.cygnus.com" ident: "meissner") by vger.rutgers.edu with ESMTP id <971124-1094>; Tue, 14 Jul 1998 15:59:06 -0400 Received: (from meissner@localhost) by tiktok.cygnus.com (8.8.7/8.8.5) id RAA10800; Tue, 14 Jul 1998 17:12:42 -0400 Date: Tue, 14 Jul 1998 17:12:42 -0400 From: Michael Meissner Message-Id: <199807142112.RAA10800@tiktok.cygnus.com> To: groudier@club-internet.fr, meissner@cygnus.com Subject: Re: TAPE problems with 3.0e of Linux NCR538XX SCSI drivers Cc: linux-kernel@vger.rutgers.edu, ncr53c810@Colorado.EDU X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO | I did enable the feature. However further testing shows something else, | presumably hardware problems is going on. I can't access the driver via either | 2.5f of the NCR53C8XX drivers or the Adaptec 2940UW driver (both of these | previously worked with the drive, and I didn't do any hardware hacking). So | now the problem is who fixes DAT drives, and what do they charge :-( Even curiouser, after switching cables, scsi adapters, etc. for 2 hours, I left and it still wasn't working, but I left the cover off. At 3am my normal dump kicked in, and it worked (on Linux 2.1.105). I'm suspecting heat now. I have an order for an external SCSI case to move the disks off to, to try and lower the temperture. Sigh.... -- Michael Meissner, Cygnus Solutions (Massachusetts office) 4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA meissner@cygnus.com, 617-354-5416 (office), 617-354-7161 (fax) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 25 13:56:57 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id NAA17397 for ; Tue, 25 Aug 1998 13:56:52 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id NAA21351 for ; Tue, 25 Aug 1998 13:56:51 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id NAA11768 for ; Tue, 25 Aug 1998 13:55:41 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id NAA15652; Tue, 25 Aug 1998 13:51:06 +0200 Received: by vger.rutgers.edu id <154512-7845>; Tue, 25 Aug 1998 04:25:10 -0400 Received: from mx03.uni-tuebingen.de ([134.2.3.13]:29257 "EHLO mx03.uni-tuebingen.de" ident: "root") by vger.rutgers.edu with ESMTP id <154983-7845>; Tue, 25 Aug 1998 04:01:02 -0400 Received: from alamak.tat.physik.uni-tuebingen.de (koenig@alamak.tat.physik.uni-tuebingen.de [134.2.170.66]) by mx03.uni-tuebingen.de (8.8.8/8.8.8) with ESMTP id LAA16259 for ; Tue, 25 Aug 1998 11:37:02 +0200 Received: (from koenig@localhost) by alamak.tat.physik.uni-tuebingen.de (8.8.8/8.8.8) id LAA29500; Tue, 25 Aug 1998 11:36:55 +0200 Message-ID: <19980825113655.03219@alamak.tat.physik.uni-tuebingen.de> Date: Tue, 25 Aug 1998 11:36:55 +0200 From: Harald Koenig To: linux-kernel-list Subject: SCSI tape blocks > 128k ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 X-fingerprint: 3B CD 5A A9 73 44 DD 04 A0 4E A0 34 20 7B 1E 38 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO I have to read SCSI tapes (DAT DDS1 this time) which have been written on non-Linux systems with blocksize >128k (512k right now, 1M possible too) but right now Linux (2.0) only supports up to 128k blocksize. is there any chance this will be changed in 2.1 or 2.3 ? if not, is there any possibility (and hopefully some tools available;) to access such devices from user space using generic scsi devices or similar ? I don't like the idea that Linux isn't possible to read pretty standard media from other OSs... Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 25 17:27:17 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id RAA19321 for ; Tue, 25 Aug 1998 17:27:16 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id RAA27015 for ; Tue, 25 Aug 1998 17:27:16 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id RAA19039 for ; Tue, 25 Aug 1998 17:26:07 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id RAA16761; Tue, 25 Aug 1998 17:22:20 +0200 Received: by vger.rutgers.edu id <154563-24313>; Tue, 25 Aug 1998 08:19:28 -0400 Received: from 3dyn248.delft.casema.net ([195.96.104.248]:12310 "EHLO rosie.BitWizard.nl" ident: "root") by vger.rutgers.edu with ESMTP id <154639-24313>; Tue, 25 Aug 1998 07:20:13 -0400 Received: from cave.BitWizard.nl (wolff@cave.BitWizard.nl [130.161.127.248]) by rosie.BitWizard.nl (8.8.5/8.8.5) with ESMTP id OAA06883; Tue, 25 Aug 1998 14:56:44 +0200 Received: (from wolff@localhost) by cave.BitWizard.nl (8.8.8/8.8.8) id OAA01174; Tue, 25 Aug 1998 14:56:43 +0200 Message-Id: <199808251256.OAA01174@cave.BitWizard.nl> Subject: Re: SCSI tape blocks > 128k ? In-Reply-To: <19980825113655.03219@alamak.tat.physik.uni-tuebingen.de> from Harald Koenig at "Aug 25, 98 11:36:55 am" To: koenig@tat.physik.uni-tuebingen.de (Harald Koenig) Date: Tue, 25 Aug 1998 14:56:43 +0200 (MEST) Cc: linux-kernel@vger.rutgers.edu From: R.E.Wolff@BitWizard.nl (Rogier Wolff) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO Harald Koenig wrote: > I have to read SCSI tapes (DAT DDS1 this time) which have been written > on non-Linux systems with blocksize >128k (512k right now, 1M possible too) > but right now Linux (2.0) only supports up to 128k blocksize. I have a patch sitting in incoming at Linux-patches@samba.anu.edu.au that would make this possible. However it seems that Linus has gotten bored of looking there, and there hasn't been any activity there for over a month now. http://samba.anu.edu.au/cgi-bin/linux-patches/incoming?id=267 The patch implements the bigbuffer support required for this use, and patches "sg" to actually use it. A two-line patch will allow st to also use this...... Roger. -- | The secret of success is sincerity. Once you can | R.E.Wolff@BitWizard.nl | fake that, you've got it made. -- Jean Giraudoux | T: +31-15-2137555 -We write Linux device drivers for any device you may have! Call for a quote- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 25 20:01:23 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id UAA20135 for ; Tue, 25 Aug 1998 20:01:22 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id UAA28440 for ; Tue, 25 Aug 1998 20:01:22 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id UAA24487 for ; Tue, 25 Aug 1998 20:00:12 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id TAA17625; Tue, 25 Aug 1998 19:56:24 +0200 Received: by vger.rutgers.edu id <154400-24313>; Tue, 25 Aug 1998 10:26:16 -0400 Received: from 3dyn248.delft.casema.net ([195.96.104.248]:12480 "EHLO rosie.BitWizard.nl" ident: "root") by vger.rutgers.edu with ESMTP id <155016-24313>; Tue, 25 Aug 1998 10:03:29 -0400 Received: from cave.BitWizard.nl (wolff@cave.BitWizard.nl [130.161.127.248]) by rosie.BitWizard.nl (8.8.5/8.8.5) with ESMTP id RAA07162; Tue, 25 Aug 1998 17:40:37 +0200 Received: (from wolff@localhost) by cave.BitWizard.nl (8.8.8/8.8.8) id RAA01680; Tue, 25 Aug 1998 17:40:36 +0200 Message-Id: <199808251540.RAA01680@cave.BitWizard.nl> Subject: Re: SCSI tape blocks > 128k ? In-Reply-To: from Alan Cox at "Aug 25, 98 05:23:17 pm" To: alan@lxorguk.ukuu.org.uk (Alan Cox) Date: Tue, 25 Aug 1998 17:40:36 +0200 (MEST) Cc: R.E.Wolff@BitWizard.nl, koenig@tat.physik.uni-tuebingen.de, linux-kernel@vger.rutgers.edu From: R.E.Wolff@BitWizard.nl (Rogier Wolff) X-Mailer: ELM [version 2.4ME+ PL37 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO Alan Cox wrote: [ Alan always cuts the attribution, but it was REW who wrote: ] > > http://samba.anu.edu.au/cgi-bin/linux-patches/incoming?id=267 > > > > The patch implements the bigbuffer support required for this use, and > > patches "sg" to actually use it. A two-line patch will allow st to > > also use this...... > > Its a workable answer, but not the right one. The right one is to propogate > the use of scatter gather better and eventually (2.3.x I hope) DMA to > user pages. Modern SCSI controllers dont need 1Mbyte of linear memory > for this. And non DMA old ones are generally sufficiently dumb you can > implement scatter gather in the cpu driven byte copy routines I agree completely that the scatter gather would be nice. However that's a 2.3 issue. The "required" I mentioned was on the assumption that this scatter/gather won't be implemented anytime soon. Video cameras and TV cards DO need linear memory, and would be able to use the bigbuffers implemented by my patch. To get my scanner working, I need a working solution. To say that a scanner is now supported under Linux, I can't afford to have to change every SCSI card driver there is. Under MSWindows, you're lucky if your scanner works with the supplied SCSI card. Try running the TWAIN driver on top of an ASPI driver for a different card (e.g. you already had a SCSI card in your PC), and it is unlikely to work. The fun thing about Linux is that once it works with one supported card, it should work with all of them. If I hack the SCSI driver that I have (NCR 810) to do the scatter gather, all the others are still lagging behind.... Roger. -- | The secret of success is sincerity. Once you can | R.E.Wolff@BitWizard.nl | fake that, you've got it made. -- Jean Giraudoux | T: +31-15-2137555 -We write Linux device drivers for any device you may have! Call for a quote- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 25 22:04:09 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id WAA20767 for ; Tue, 25 Aug 1998 22:04:09 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id WAA29132 for ; Tue, 25 Aug 1998 22:04:08 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id WAA01362 for ; Tue, 25 Aug 1998 22:02:59 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id VAA18370; Tue, 25 Aug 1998 21:59:22 +0200 Received: by vger.rutgers.edu id <155221-24313>; Tue, 25 Aug 1998 12:33:21 -0400 Received: from mx03.uni-tuebingen.de ([134.2.3.13]:13554 "EHLO mx03.uni-tuebingen.de" ident: "root") by vger.rutgers.edu with ESMTP id <154638-24313>; Tue, 25 Aug 1998 10:27:00 -0400 Received: from alamak.tat.physik.uni-tuebingen.de (koenig@alamak.tat.physik.uni-tuebingen.de [134.2.170.66]) by mx03.uni-tuebingen.de (8.8.8/8.8.8) with ESMTP id SAA28427 for ; Tue, 25 Aug 1998 18:03:58 +0200 Received: (from koenig@localhost) by alamak.tat.physik.uni-tuebingen.de (8.8.8/8.8.8) id SAA03296; Tue, 25 Aug 1998 18:03:50 +0200 Message-ID: <19980825180350.20748@alamak.tat.physik.uni-tuebingen.de> Date: Tue, 25 Aug 1998 18:03:50 +0200 From: Harald Koenig To: linux-kernel-list Subject: Re: SCSI tape blocks > 128k ? References: <199808251256.OAA01174@cave.BitWizard.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.89.1 In-Reply-To: ; from Alan Cox on Tue, Aug 25, 1998 at 05:23:17PM +0100 X-fingerprint: 3B CD 5A A9 73 44 DD 04 A0 4E A0 34 20 7B 1E 38 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO On Aug 25, Alan Cox wrote: > > http://samba.anu.edu.au/cgi-bin/linux-patches/incoming?id=267 > > > > The patch implements the bigbuffer support required for this use, and > > patches "sg" to actually use it. A two-line patch will allow st to > > also use this...... > > Its a workable answer, but not the right one. The right one is to propogate > the use of scatter gather better and eventually (2.3.x I hope) DMA to > user pages. Modern SCSI controllers dont need 1Mbyte of linear memory > for this. And non DMA old ones are generally sufficiently dumb you can > implement scatter gather in the cpu driven byte copy routines but at least my setup is just in the middle of these two extremes: the DAT is connected to a good old AHA1542B (it's only for external devices which can be hot-plughed without risk; I don't need to touch the SCSI bus for faster disks), so I need DMA and can't use scatter gather (AFAIK)... having bigbuffer support addtional to a better scatter gather method for more recent hardware would be the best thing[tm] (and that's what Linux is trying to be, isn't it?;) Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Aug 25 19:58:46 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id TAA20093 for ; Tue, 25 Aug 1998 19:58:45 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id TAA28399 for ; Tue, 25 Aug 1998 19:58:45 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id TAA24338 for ; Tue, 25 Aug 1998 19:57:36 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id TAA17586; Tue, 25 Aug 1998 19:52:12 +0200 Received: by vger.rutgers.edu id <154318-24313>; Tue, 25 Aug 1998 10:26:03 -0400 Received: from snowcrash.cymru.net ([163.164.160.3]:1109 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <154980-24313>; Tue, 25 Aug 1998 09:49:15 -0400 Received: from the-village.bc.nu (the-village.bc.nu [163.164.160.21]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id QAA13075; Tue, 25 Aug 1998 16:26:26 +0100 Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zBLsN-000aQ2C; Tue, 25 Aug 98 17:23 BST Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: SCSI tape blocks > 128k ? To: R.E.Wolff@BitWizard.nl (Rogier Wolff) Date: Tue, 25 Aug 1998 17:23:17 +0100 (BST) Cc: koenig@tat.physik.uni-tuebingen.de, linux-kernel@vger.rutgers.edu In-Reply-To: <199808251256.OAA01174@cave.BitWizard.nl> from "Rogier Wolff" at Aug 25, 98 02:56:43 pm Content-Type: text X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO > http://samba.anu.edu.au/cgi-bin/linux-patches/incoming?id=267 > > The patch implements the bigbuffer support required for this use, and > patches "sg" to actually use it. A two-line patch will allow st to > also use this...... Its a workable answer, but not the right one. The right one is to propogate the use of scatter gather better and eventually (2.3.x I hope) DMA to user pages. Modern SCSI controllers dont need 1Mbyte of linear memory for this. And non DMA old ones are generally sufficiently dumb you can implement scatter gather in the cpu driven byte copy routines Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Aug 26 01:03:45 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id BAA21369 for ; Wed, 26 Aug 1998 01:03:45 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id BAA29757 for ; Wed, 26 Aug 1998 01:03:45 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id BAA05884 for ; Wed, 26 Aug 1998 01:02:36 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id BAA19431; Wed, 26 Aug 1998 01:02:05 +0200 Received: by vger.rutgers.edu id <154913-24313>; Tue, 25 Aug 1998 15:48:58 -0400 Received: from snowcrash.cymru.net ([163.164.160.3]:1572 "EHLO snowcrash.cymru.net" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <155111-24313>; Tue, 25 Aug 1998 14:25:10 -0400 Received: from the-village.bc.nu (the-village.bc.nu [163.164.160.21]) by snowcrash.cymru.net (8.8.7/8.7.1) with SMTP id VAA18649; Tue, 25 Aug 1998 21:02:56 +0100 Received: by the-village.bc.nu (Smail3.1.29.1 #2) id m0zBQBx-000aPLC; Tue, 25 Aug 98 21:59 BST Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: SCSI tape blocks > 128k ? To: koenig@tat.physik.uni-tuebingen.de (Harald Koenig) Date: Tue, 25 Aug 1998 21:59:47 +0100 (BST) Cc: linux-kernel@vger.rutgers.edu In-Reply-To: <19980825180350.20748@alamak.tat.physik.uni-tuebingen.de> from "Harald Koenig" at Aug 25, 98 06:03:50 pm Content-Type: text X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO > having bigbuffer support addtional to a better scatter gather method > for more recent hardware would be the best thing[tm] (and that's what Linux > is trying to be, isn't it?;) I thought the 1542B and later 1542A had scatter gather ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Sep 16 02:43:44 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA02221 for ; Wed, 16 Sep 1998 02:43:43 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA20184 for ; Wed, 16 Sep 1998 02:43:38 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id CAA01274 for ; Wed, 16 Sep 1998 02:42:28 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id CAA14409; Wed, 16 Sep 1998 02:41:56 +0200 Received: by vger.rutgers.edu id <154784-22478>; Tue, 15 Sep 1998 16:40:40 -0400 Received: from vindaloo.atnf.CSIRO.AU ([130.155.198.47]:1274 "HELO vindaloo.atnf.CSIRO.AU" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with SMTP id <154964-22478>; Tue, 15 Sep 1998 16:21:48 -0400 Received: (from rgooch@localhost) by vindaloo.atnf.CSIRO.AU (8.6.12/8.6.12) id JAA04954; Wed, 16 Sep 1998 09:32:20 +1000 Date: Wed, 16 Sep 1998 09:32:20 +1000 Message-Id: <199809152332.JAA04954@vindaloo.atnf.CSIRO.AU> From: Richard Gooch To: michael@amintech.com Cc: linux-kernel@vger.rutgers.edu, davem@dm.cobaltmicro.com Subject: Re: tapefs In-Reply-To: <199809152041.PAA06377@mydot.com> References: <199809152041.PAA06377@mydot.com> Notfrom: spamlog@atnf.csiro.au X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO [Cc'ed to linux-kernel instead, Bcc'ed to linux-scsi for reference] [DaveM: it's not clear to me if the linux-fsdevel list is for VFS dicussions or for *all* FS development discussions] Michael Wilhelm writes: > I am looking for a tapefs or some type of program that may make a > nfs server using the tapedrive as a disk drive or a ftp server that > uses the tape drive as a disk drive... I have seen > unitree(www.unitree.com) but its not for linux.. any suggestions? I'm not entirely sure what you mean by "tapefs". I looked at the Unitree WWW pages and it appears the only product they offer is a heirarchical file storage system. This is a system which will backup unused files to long-term storage media (i.e. tapes). The file entry still appears in the filesystem (as would the inode permissions and such), it's just that the data blocks are marked as not available. When a process tries to access the data blocks in such a file, the data is migrated back to disc (obviously this can be a slow operation:-). These systems have a robot tape-loading machine associated with them and a roomful of tapes. However, this is not what I'd call a tapefs. I'd call it a heirfs or something. Our director here has pushed for this kind of system for around 10 years now :-) Unfortunately, they are quite expensive. Having such a system (the heirfs software and an API to drive robots) for Linux would certainly make it attractive to "big iron" users. I believe there are some commodity tape robots which are affordable. A commercial heirfs solution is likely to charge an awful lot just for the software. A free Linux heirfs would get around that. To me, a tapefs is a FS that allows me to mount a tape and gives the appearance of a (cough) slow filesystem. This is something I've had users (colleagues with large scientific datasets) ask me about, and is something that would be quite handy. Both these filesystems *could* be done in userspace, either by hacking libc to wrap all the FS calls, or by creating a pseudo-NFS server which "exports" it's FS which is locally mounted. The libc hacking solution has the disadvantage of not working for older applications using older C libraries or statically linked. It also has the disadvantage of adding a layer and hence performance overhead for *all* file accesses. The pseudo-NFS server solution has the disadvantage of requiring all file I/O for the FS to go through the NFS layers, which would drastically reduce performance. For a heirfs, this is bad, since it would be used for massive datasets, so the performance loss would really hurt. For a tapefs, the loss might not be as great, since some tapes (exebyte) tend not to be so fast anyway. A DLT, on the other hand, is pretty fast, so once again going through NFS layers will cause a noticable degradation. So, implementing a real FS module for each of these systems would probably be the right way to go. What we need is someone with the time and energy to go forth and write code. Any takers? Regards, Richard.... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Sep 16 04:21:55 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id EAA02534 for ; Wed, 16 Sep 1998 04:21:55 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id EAA21750 for ; Wed, 16 Sep 1998 04:21:55 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id EAA02585 for ; Wed, 16 Sep 1998 04:20:44 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id EAA14977; Wed, 16 Sep 1998 04:17:12 +0200 Received: by vger.rutgers.edu id <154562-22478>; Tue, 15 Sep 1998 18:40:40 -0400 Received: from vindaloo.atnf.CSIRO.AU ([130.155.198.47]:1308 "HELO vindaloo.atnf.CSIRO.AU" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with SMTP id <154626-22478>; Tue, 15 Sep 1998 17:56:18 -0400 Received: (from rgooch@localhost) by vindaloo.atnf.CSIRO.AU (8.6.12/8.6.12) id LAA05687; Wed, 16 Sep 1998 11:07:23 +1000 Date: Wed, 16 Sep 1998 11:07:23 +1000 Message-Id: <199809160107.LAA05687@vindaloo.atnf.CSIRO.AU> From: Richard Gooch To: Dan Hollis Cc: linux-kernel@vger.rutgers.edu Subject: Re: tapefs In-Reply-To: References: <199809152332.JAA04954@vindaloo.atnf.CSIRO.AU> Notfrom: spamlog@atnf.csiro.au X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Dan Hollis writes: > On Wed, 16 Sep 1998, Richard Gooch wrote: > > So, implementing a real FS module for each of these systems would > > probably be the right way to go. What we need is someone with the time > > and energy to go forth and write code. Any takers? > > Someone implemented this back in '96 on Linux. A Linux Tape-Filesystem. > The URL used to be > http://www.Worms.Fh-Rpl.DE/~oppersk/tfs-html/tfs.engl.html > but that domain does not seem to exist anymore. Im doing some digging > around to see where its gone to. Great. Keep us posted! It's a shame it was never included into the kernel. Regards, Richard.... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Sep 16 05:33:35 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA02603 for ; Wed, 16 Sep 1998 05:33:35 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA21937 for ; Wed, 16 Sep 1998 05:33:33 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id FAA03681 for ; Wed, 16 Sep 1998 05:32:23 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id FAA15460; Wed, 16 Sep 1998 05:32:03 +0200 Received: by vger.rutgers.edu id <154541-22478>; Tue, 15 Sep 1998 20:09:58 -0400 Received: from chaos.analogic.com ([204.178.40.224]:1292 "EHLO chaos.analogic.com" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <154820-22478>; Tue, 15 Sep 1998 19:59:21 -0400 Received: (from root@localhost) by chaos.analogic.com (8.7.5/8.7.3) id DAA00665; Wed, 16 Sep 1998 03:10:01 GMT Date: Tue, 15 Sep 1998 23:10:01 -0400 (EDT) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Richard Gooch cc: michael@amintech.com, linux-kernel@vger.rutgers.edu, davem@dm.cobaltmicro.com Subject: Re: tapefs In-Reply-To: <199809152332.JAA04954@vindaloo.atnf.CSIRO.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O A tape file-system by any name is just a program (read user-mode) that puts directories for all the files on the tape SOMEWHERE. You can preallocate some blocks at the beginning for a directory that contains directory information plus the starting offset tape block, or you can put directory information between the files themselves. Both methods have been used by Digital. You can make a RMS file-system on a tape and then "mount" it, or you can mount a raw tape (called "foreign" in DEC lingo). Note that `tar` creates a "file-system" on the tape so you can restore individual files, etc. The problem is that a tape is a sequential device. You can't extend a file, you can't delete a file (although you can pretend to by marking its directory entry deleted). The result is a write-once file-system with abysmal performance. In the "olden" days, we had reel-to-reel tapes that could "seek". These tapes could rapidly find "file-marks" so you could get some random-access. The modern tape drives don't "remember" where they are, so to count file-marks, you have to rewind and start from the beginning. They are just not designed for random access. Nevertheless, a user-mode program can be written to process file- system data, buffer it to improve performance, and write dirty buffers to a tape. You can even run such a program as a daemon and "mount" it so, to a user, it looks like an ext2 file-system. It becomes basically a RAM disk, with overflow , and everything necessary to restore it, written to the tape. However, before you write such a thing, experiment with a simple program that opens/writes/rewinds/reads your tape. The performance you get is positively awful. I've done this to stream raw data to a SCSI Tape, once it gets going, it's okay. However, a rewind to read takes ...er well, maybe you can compile the kernel while you are waiting. FYI, the source-code for `mt` contains everything you need to know about accessing these beasties. Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips). Warning : It's hard to remain at the trailing edge of technology. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Sep 16 14:30:50 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA10874 for ; Wed, 16 Sep 1998 14:30:50 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA15937 for ; Wed, 16 Sep 1998 14:30:46 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id OAA06987 for ; Wed, 16 Sep 1998 14:29:36 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id OAA18063; Wed, 16 Sep 1998 14:28:22 +0200 Received: by vger.rutgers.edu id <154333-21976>; Wed, 16 Sep 1998 05:11:18 -0400 Received: from mydot.com ([207.50.46.227]:12445 "EHLO mydot.com" ident: "root") by vger.rutgers.edu with ESMTP id <154318-21976>; Wed, 16 Sep 1998 05:11:10 -0400 Received: from scooby.mydot.com (scooby.mydot.com [207.50.46.231]) by mydot.com (8.8.7/8.8.7) with SMTP id HAA01593; Wed, 16 Sep 1998 07:30:35 -0500 Message-Id: <199809161230.HAA01593@mydot.com> From: "Michael Wilhelm" Organization: Reflection Studios To: linux-kernel@vger.rutgers.edu, davem@dm.cobaltmicro.com Date: Wed, 16 Sep 1998 07:22:35 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: tapefs Reply-to: michael@amintech.com References: <199809152332.JAA04954@vindaloo.atnf.CSIRO.AU> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.01b) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O > > A tape file-system by any name is just a program (read user-mode) > that puts directories for all the files on the tape SOMEWHERE. > > You can preallocate some blocks at the beginning for a directory > that contains directory information plus the starting offset tape > block, or you can put directory information between the files > themselves. Both methods have been used by Digital. You can make > a RMS file-system on a tape and then "mount" it, or you can > mount a raw tape (called "foreign" in DEC lingo). Note that > `tar` creates a "file-system" on the tape so you can restore > individual files, etc. > > The problem is that a tape is a sequential device. You can't extend > a file, you can't delete a file (although you can pretend to by > marking its directory entry deleted). > > The result is a write-once file-system with abysmal performance. > In the "olden" days, we had reel-to-reel tapes that could "seek". > These tapes could rapidly find "file-marks" so you could get some > random-access. The modern tape drives don't "remember" where they > are, so to count file-marks, you have to rewind and start from > the beginning. They are just not designed for random access. I would have to disagree with this... a lot of high end SCSI drives like dat, or dlt drives can randomly acesss the tape. you can seek to any point on the drive.. I have a scsi dat that that way I can write a tar file then type in mt tell and it will tell me it position take the tape out place it back in type in mt seek number (number is the number i got from mt tell) and it will seek to that point with in less than 5-10 sec. so I still think that a tape fs can be writen with some farly quick response time.. > Nevertheless, a user-mode program can be written to process file- > system data, buffer it to improve performance, and write dirty > buffers to a tape. You can even run such a program as a daemon > and "mount" it so, to a user, it looks like an ext2 file-system. > > It becomes basically a RAM disk, with overflow , and everything > necessary to restore it, written to the tape. > > However, before you write such a thing, experiment with a simple > program that opens/writes/rewinds/reads your tape. The performance > you get is positively awful. I've done this to stream raw data > to a SCSI Tape, once it gets going, it's okay. However, a rewind > to read takes ...er well, maybe you can compile the kernel while > you are waiting. > > FYI, the source-code for `mt` contains everything you need to know > about accessing these beasties. > > Cheers, > Dick Johnson > ***** FILE SYSTEM WAS MODIFIED ***** > Penguin : Linux version 2.1.118 on an i586 machine (66.15 BogoMips). > Warning : It's hard to remain at the trailing edge of technology. ------------ Michael W. Check out this web site: http://mydot.com Boycott Internet Spam! http://spam.abuse.net/spam/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Sep 17 14:08:31 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA32433 for ; Thu, 17 Sep 1998 14:08:22 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA20431 for ; Thu, 17 Sep 1998 14:08:19 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id OAA12018 for ; Thu, 17 Sep 1998 14:07:11 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id OAA24943; Thu, 17 Sep 1998 14:05:49 +0200 Received: by vger.rutgers.edu id <154851-8088>; Thu, 17 Sep 1998 04:42:31 -0400 Received: from mhw.ulib.iupui.edu ([134.68.164.123]:1042 "EHLO mhw.ULib.IUPUI.Edu" ident: "root") by vger.rutgers.edu with ESMTP id <154825-8088>; Thu, 17 Sep 1998 04:26:19 -0400 Received: from localhost (4883 bytes) by mhw.ULib.IUPUI.Edu via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Thu, 17 Sep 1998 06:45:29 -0500 (EST) (Smail-3.2.0.101 1997-Dec-17 #2 built 1998-Jun-1) Date: Thu, 17 Sep 1998 06:45:28 -0500 (EST) From: "Mark H. Wood" X-Sender: mwood@mhw.ULib.IUPUI.Edu cc: linux-kernel@vger.rutgers.edu Subject: Re: tapefs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: unlisted-recipients:; (no To-header on input) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Tue, 15 Sep 1998, Richard B. Johnson wrote: > A tape file-system by any name is just a program (read user-mode) > that puts directories for all the files on the tape SOMEWHERE. > > You can preallocate some blocks at the beginning for a directory > that contains directory information plus the starting offset tape > block, Actually the DECtape directory block was block 100 IIRC. The ends of the tape get beat up more readily than the middle, so you want the critical filesystem info. buried in the tape pack where it's a little safer. Anyway that's my guess as to why block 100. (Oops! was that 100 decimal or octal? :-) > or you can put directory information between the files > themselves. Both methods have been used by Digital. This approach simply adds system-specific information to the portions of standard ANSI tape label groups which are reserved for user specification. A handy thing it is, too, as long as you don't care how long it takes to open a file. > You can make > a RMS file-system on a tape and then "mount" it, or you can > mount a raw tape (called "foreign" in DEC lingo). Note that > `tar` creates a "file-system" on the tape so you can restore > individual files, etc. On VMS, tape files had not only names but ownership and protection masks as well. It worked pretty well when the tapes were kept behind the I/O window and you had to present yourself physically and sign out a tape in order to take it to another site and circumvent the protection. Nowadays, when one could just pick up the whole computer system and carry it off when nobody is looking, I guess that aspect is not so useful. > The problem is that a tape is a sequential device. You can't extend > a file, you can't delete a file (although you can pretend to by > marking its directory entry deleted). This is not true of DECtape, which has a separate timing track to mark fixed blocks and is formatted more like a disk. Files were threaded together with next-block pointers in each file block, and random access (either physically, or logically within files) was possible -- again assuming that you don't mind waiting. Nowadays this is a rather useless bit of knowledge since nobody makes drives like that anymore, but it *has* been done. The thing that made seeking on DECtape bearable was that the things were less than 600 blocks long. > The result is a write-once file-system with abysmal performance. > In the "olden" days, we had reel-to-reel tapes that could "seek". > These tapes could rapidly find "file-marks" so you could get some > random-access. The modern tape drives don't "remember" where they > are, so to count file-marks, you have to rewind and start from > the beginning. They are just not designed for random access. The driver could take care of maintaining the tapemark count, and as I recall it usually did. Where did you see drives that counted tapemarks in hardware? But I agree that tape drives are not designed for random access, at least not as the usual mode of use and not in the way we are accustomed to think of it. More DECtape trivia: the seek code would compare current position to desired position, start the correct hub motor, calculate how long it would take to get fairly near the desired block, and set a timer. When awakened it would ask the drive which block had last gone by and do the right thing. Tape speed was nearly constant since the tiny reels weighed only a few ounces, so the calculation was pretty simple. [Interesting idea for a RAMdisk with tape as backing store omitted] One of the things I really miss in the Unix world is labelled tapes. Tape volumes are not so cheap that I'm not sorely tempted to put multiple files on a tape, but then I have to keep my own manual records of which one is which and I know what would happen *then*. :-/ Having named files on tape was so nice that I've often toyed with the idea of writing a driver that would take over a physical tape drive and add ANSI file/label semantics (but to date I haven't gone so far as to code anything). I know it'd be slow, but us old fogeys *knew* tape was slow and used it appropriately. Usually most of the delay in tape storage/retrieval was caused by the operators, not the transport. :-) -- Mark H. Wood, Lead System Programmer mwood@IUPUI.Edu Speaking of DECtape, ask me about the DATE75 project. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Mon Sep 21 05:21:07 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA01869 for ; Mon, 21 Sep 1998 05:21:07 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA24855 for ; Mon, 21 Sep 1998 05:21:06 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id FAA29819 for ; Mon, 21 Sep 1998 05:20:05 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id FAA16948; Mon, 21 Sep 1998 05:19:43 +0200 Received: by vger.rutgers.edu id <154713-16160>; Sun, 20 Sep 1998 17:15:54 -0400 Received: from p15.hh.shuttle.de ([194.95.238.15]:1150 "EHLO ds9.oxygen.org" ident: "root") by vger.rutgers.edu with ESMTP id <154614-16160>; Sun, 20 Sep 1998 15:09:21 -0400 Received: from ds9 (jens@localhost [127.0.0.1]) by ds9.oxygen.org (8.8.8/8.8.8) with SMTP id XAA00696; Fri, 18 Sep 1998 23:52:26 +0200 From: Jens Benecke To: root@chaos.analogic.com Subject: Re: tapefs Date: Fri, 18 Sep 1998 23:45:53 +0200 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain References: Cc: linux-kernel@vger.rutgers.edu MIME-Version: 1.0 Message-Id: <98091823522500.00671@ds9> Content-Transfer-Encoding: 8bit X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Am Wed, 16 Sep 1998 schrieb Richard B. Johnson: >A tape file-system by any name is just a program (read user-mode) >that puts directories for all the files on the tape SOMEWHERE. .... >The problem is that a tape is a sequential device. You can't extend >a file, you can't delete a file (although you can pretend to by >marking its directory entry deleted). >The result is a write-once file-system with abysmal performance. The only thing I can remark about this is that I used to have a programm ('TSR') under DOS that did exactly this - it allocated AFAIR 2MB of RAM for buffers and I was able to play Command & Conquer 2 from Tape instead of CDROM, which was much faster than my 2x CDROM those days. So, it _is_ possible. Whether a Linux port would fail at some (missing) kernel feature I cannot say. Something which IMHO would be much more interesting would be a cdrfs, like Spica CD Manager (Windows) or RSJ CD Writer (OS/2). You mount the CDR, it allocates a buffer on hard disk (20MB default), you cp, mv, ls, rm on this mounted CDR, it writes to the buffer and when the buffer is full, it burns a track on CDR. If the buffer keeps filling (e.g. a cp -a job), it just keeps burning, if the buffer empties, it closes the track and waits for it to fill up again. For file system it allocates a 1MB track at the beginning of the CDR which is being written at umount time. -- ciao, Jens http://www.pinguin.conetix.de * Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine Gefährten nicht zählen brauchte. -- Karl May, Winnetou, Band 3 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sat Sep 19 14:23:21 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA26337 for ; Sat, 19 Sep 1998 14:23:21 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA14264 for ; Sat, 19 Sep 1998 14:23:20 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id OAA21679 for ; Sat, 19 Sep 1998 14:22:16 +0200 (MET DST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id OAA06556; Sat, 19 Sep 1998 14:21:52 +0200 Received: by vger.rutgers.edu id <154036-16160>; Sat, 19 Sep 1998 04:45:54 -0400 Received: from ns.imp.ch ([157.161.1.2]:4711 "EHLO mail.imp.ch" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <153867-16160>; Sat, 19 Sep 1998 04:45:41 -0400 Received: from impch.imp.ch (impch.imp.ch [157.161.1.1]) by mail.imp.ch (8.8.8/8.8.5) with SMTP id OAA22426 for ; Sat, 19 Sep 1998 14:18:19 +0200 (MET DST) Received: by impch.imp.ch with UUCP (5.65b/IDA-052490) id AA03629; Sat, 19 Sep 98 12:18:17 GMT Received: (from news@localhost) by vulcan.alphanet.ch (8.8.5/8.7.3) id NAA32508 for linux-kernel@vger.rutgers.edu; Sat, 19 Sep 1998 13:37:16 +0200 To: linux-kernel@vger.rutgers.edu Path: alphanet.ch!not-for-mail From: Marc SCHAEFER Newsgroups: alphanet.ml.linux.kernel Subject: Re: tapefs Date: 19 Sep 1998 13:37:12 +0200 Organization: ALPHANET NF -- Not for profit telecom research Lines: 11 Distribution: alphanet Message-Id: <6u0518$vnk$1@vulcan.alphanet.ch> References: <6tnajq$uj5$1@vulcan.alphanet.ch> Nntp-Posting-Host: vulcan.alphanet.ch X-Newsreader: TIN [UNIX 1.3 unoff BETA 970705; i586 Linux 2.0.35] Xref: alphanet.ch alphanet.ml.linux.kernel:40815 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Dan Hollis wrote: > Someone implemented this back in '96 on Linux. A Linux Tape-Filesystem. > The URL used to be > http://www.Worms.Fh-Rpl.DE/~oppersk/tfs-html/tfs.engl.html > but that domain does not seem to exist anymore. Im doing some digging > around to see where its gone to. I remember having tried a DDS-2 drive with the tapefs filesystem in the userfs distribution. It worked (read-only). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Sep 22 11:25:32 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id LAA19968 for ; Tue, 22 Sep 1998 11:25:28 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id LAA07753 for ; Tue, 22 Sep 1998 11:25:27 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id LAA18477 for ; Tue, 22 Sep 1998 11:24:28 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id LAA26409; Tue, 22 Sep 1998 11:23:26 +0200 Received: by vger.rutgers.edu id <154064-16160>; Tue, 22 Sep 1998 01:24:05 -0400 Received: from atrey.karlin.mff.cuni.cz ([195.113.31.123]:1621 "EHLO atrey.karlin.mff.cuni.cz" ident: "TIMEDOUT2") by vger.rutgers.edu with ESMTP id <154188-16160>; Tue, 22 Sep 1998 01:20:31 -0400 Received: from Elf.ucw.cz (slip14.ms.mff.cuni.cz [195.113.20.214]) by atrey.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id LAA09621; Tue, 22 Sep 1998 11:11:00 +0200 Received: from bug.ucw.cz (pavel@bug.ucw.cz [10.0.0.3]) by Elf.ucw.cz (8.8.8/8.8.5) with ESMTP id MAA00122; Mon, 21 Sep 1998 12:07:19 +0200 Received: (from pavel@localhost) by bug.ucw.cz (8.8.5/8.8.5) id MAA01552; Mon, 21 Sep 1998 12:07:17 +0200 Message-ID: <19980921120717.60808@bug.ucw.cz> Date: Mon, 21 Sep 1998 12:07:17 +0200 From: Pavel Machek To: Jens Benecke Cc: root@chaos.analogic.com, linux-kernel@vger.rutgers.edu Subject: Re: tapefs References: <98091823522500.00671@ds9> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <98091823522500.00671@ds9>; from Jens Benecke on Fri, Sep 18, 1998 at 11:45:53PM +0200 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Hi! > Something which IMHO would be much more interesting would be a cdrfs, like Spica > CD Manager (Windows) or RSJ CD Writer (OS/2). You mount the CDR, it allocates a > buffer on hard disk (20MB default), you cp, mv, ls, rm on this mounted CDR, it > writes to the buffer and when the buffer is full, it burns a track on CDR. If > the buffer keeps filling (e.g. a cp -a job), it just keeps burning, if the > buffer empties, it closes the track and waits for it to fill up again. For file > system it allocates a 1MB track at the beginning of the CDR which is being > written at umount time. Hmm, nice. It might be nice to do this in generic way: kind of overlay fs. You have local hdd and nfs. You decide to have 20MB cache for nfs on local disk... If you went for special case of cdrfs, userland solution would probably be acceptable and not-so-hard to do (http://atrey/~pavel/podfuk/podfuk.html). Pavel -- I'm really pavel@atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sun Sep 27 18:58:24 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA16276 for ; Sun, 27 Sep 1998 18:58:24 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA24416 for ; Sun, 27 Sep 1998 18:58:23 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id SAA26145 for ; Sun, 27 Sep 1998 18:57:34 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id SAA26272; Sun, 27 Sep 1998 18:57:11 +0200 Received: by vger.rutgers.edu id <154197-4055>; Sun, 27 Sep 1998 08:25:18 -0400 Received: from p36.hh.shuttle.de ([194.95.238.36]:1077 "EHLO ds9.oxygen.org" ident: "root") by vger.rutgers.edu with ESMTP id <154062-4055>; Sun, 27 Sep 1998 08:21:03 -0400 Received: from ds9 (jens@localhost [127.0.0.1]) by ds9.oxygen.org (8.8.8/8.8.8) with SMTP id MAA23335; Sat, 26 Sep 1998 12:00:17 +0200 From: Jens Benecke To: Pavel Machek Subject: Re: tapefs Date: Sat, 26 Sep 1998 11:59:47 +0200 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain; charset=US-ASCII References: <19980921120717.60808@bug.ucw.cz> MIME-Version: 1.0 Message-Id: <98092603055406.09103@ds9> Content-Transfer-Encoding: 7BIT Cc: linux-kernel@vger.rutgers.edu X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Am Mon, 21 Sep 1998 schriebst Du: >> Something which IMHO would be much more interesting would be a cdrfs, like Spica >> CD Manager (Windows) or RSJ CD Writer (OS/2). You mount the CDR, it allocates a >> buffer on hard disk (20MB default), you cp, mv, ls, rm on this mounted CDR, it >> writes to the buffer and when the buffer is full, it burns a track on CDR. If >> the buffer keeps filling (e.g. a cp -a job), it just keeps burning, if the >> buffer empties, it closes the track and waits for it to fill up again. For file >> system it allocates a 1MB track at the beginning of the CDR which is being >> written at umount time. > Hmm, nice. It might be nice to do this in generic way: kind of overlay > fs. You have local hdd and nfs. You decide to have 20MB cache for nfs > on local disk... sure. If I knew anything about programming, I'd have done it long ago ... buffering slow media on fast ones has already been done, it's called cache. Now we are talking about buffering _very_ slow media on _medium_ fast ones. I wonder if that is so much different or if one could simply extend the filesystem cache code ... -- _ciao, Jens_______________________________http://www.pinguin.conetix.de_ cat /dev/boiler/water | tea | sieve > /cup mount -t hdev /dev/human/mouth01 /mouth cat /cup >/mouth/gulp __________________________________________________________________________________ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sun Sep 27 21:56:37 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id VAA16875 for ; Sun, 27 Sep 1998 21:56:36 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id VAA25010 for ; Sun, 27 Sep 1998 21:56:35 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id VAA29535 for ; Sun, 27 Sep 1998 21:55:46 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id VAA27089; Sun, 27 Sep 1998 21:55:21 +0200 Received: by vger.rutgers.edu id <154272-4055>; Sun, 27 Sep 1998 11:17:38 -0400 Received: from tartu.cyber.ee ([193.40.16.128]:2071 "EHLO tartu.cyber.ee" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with ESMTP id <154289-4055>; Sun, 27 Sep 1998 11:04:31 -0400 Received: from roos.tartu-labor (mroos@roos.tartu-labor [192.168.74.3]) by tartu.cyber.ee (8.8.3/8.7.3) with ESMTP id WAA13655; Sun, 27 Sep 1998 22:26:50 +0300 Received: (from mroos@localhost) by roos.tartu-labor (8.8.7/8.8.7) id WAA03710; Sun, 27 Sep 1998 22:26:48 +0300 Date: Sun, 27 Sep 1998 22:26:48 +0300 From: Meelis Roos Message-Id: <199809271926.WAA03710@roos.tartu-labor> To: jens@mail.conetix.de, linux-kernel@vger.rutgers.edu Subject: Re: tapefs In-Reply-To: <19980921120717.60808@bug.ucw.cz> <98092603055406.09103@ds9> User-Agent: tin/pre-1.4-980818 ("Laura") (UNIX) (Linux/2.1.119 (i586)) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O JB> cat /dev/boiler/water | tea | sieve > /cup JB> mount -t hdev /dev/human/mouth01 /mouth JB> cat /cup >/mouth/gulp egrep -v 'peel+|seed+' < orange* > mouth (a little unsure about the English translation) -- Meelis Roos (mroos@tartu.cyber.ee) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sat Oct 10 05:29:45 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA29277 for ; Sat, 10 Oct 1998 05:29:44 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA12214 for ; Sat, 10 Oct 1998 05:29:44 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id FAA13180 for ; Sat, 10 Oct 1998 05:28:14 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id FAA14845; Sat, 10 Oct 1998 05:27:57 +0200 Received: by vger.rutgers.edu id <155131-662>; Fri, 9 Oct 1998 16:29:27 -0400 Received: from [195.222.200.241] ([195.222.200.241]:4525 "EHLO psyche.kn-bremen.de" ident: "mail") by vger.rutgers.edu with ESMTP id <155582-662>; Fri, 9 Oct 1998 14:55:23 -0400 Received: from plate by psyche.kn-bremen.de with local (Exim 2.04 #1 (Debian)) id 0zRm4c-0004pn-00; Sat, 10 Oct 1998 01:35:50 +0200 To: linux kernel list Subject: Re: Scsi tape - returns ENXIO after an error References: <361D4E9E.B1962B00@actcom.co.il> <19981009115424.A20252@tat.physik.uni-tuebingen.de> From: Joerg Plate Reply-To: Joerg Plate Date: 10 Oct 1998 01:35:50 +0200 In-Reply-To: Harald Koenig's message of "Fri, 9 Oct 1998 11:54:24 +0200" Message-ID: <87u31dnwa1.fsf@psyche.kn-bremen.de> Lines: 18 User-Agent: Gnus/5.070033 (Pterodactyl Gnus v0.33) XEmacs/21.0 (Irish Goat) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O I have no problems. /proc/scsi/scsi Host: scsi0 Channel: 00 Id: 05 Lun: 00 Vendor: SONY Model: SDT-5000 Rev: 3.30 Type: Sequential-Access ANSI SCSI revision: 02 /proc/scsi/ncr53c8xx/0 (FirePort40+"ncr53c8xx - revision 3.0i") Chip NCR53C875J, device id 0x8f, revision id 0x4 IO port address 0x6c00, IRQ number 10 Using memory mapped IO at virtual address 0xc8800000 Synchronous period factor 12, max commands per lun 32 /proc/version Linux version 2.1.124 (root@psyche) (gcc version pgcc-2.91.57 19980901 (egcs-1.1 release)) -- "i'm working on it" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sat Oct 10 05:59:03 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA29390 for ; Sat, 10 Oct 1998 05:59:03 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id FAA12259 for ; Sat, 10 Oct 1998 05:59:02 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id FAA13523 for ; Sat, 10 Oct 1998 05:57:32 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id FAA15016; Sat, 10 Oct 1998 05:50:33 +0200 Received: by vger.rutgers.edu id <154804-662>; Fri, 9 Oct 1998 17:05:56 -0400 Received: from surf172.bur.adelphia.net ([24.48.40.172]:1196 "HELO air.fast.net" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with SMTP id <156197-662>; Fri, 9 Oct 1998 15:17:45 -0400 Received: from localhost (hirsch@localhost) by air.fast.net (8.6.12/8.6.9) with SMTP id UAA01310; Fri, 9 Oct 1998 20:57:36 -0400 X-Authentication-Warning: air.fast.net: hirsch owned process doing -bs Date: Fri, 9 Oct 1998 20:57:35 -0400 (EDT) From: "Steven N. Hirsch" X-Sender: hirsch@air.fast.net To: Harald Koenig cc: linux kernel list Subject: Re: Scsi tape - returns ENXIO after an error In-Reply-To: <19981009115424.A20252@tat.physik.uni-tuebingen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Fri, 9 Oct 1998, Harald Koenig wrote: > On Oct 09, Itai Nahshon wrote: > > > Hello, > > I got a new DDS2 tape drive (Sony SDT-7000). I'm trying to read > > an old tape (probably not compatible) and I'm getting this error: > > > > nahshon# tar vtf /dev/st0 > > tar: Read error on /dev/st0: I/O error > > tar: At beginning of tape, quitting now > > > > Later, I cannot use the tape drive: > > > > nahshon# tar vtf /dev/st0 > > tar: Cannot open /dev/st0: No such device or address > > > > The only way to recover is to unload and reload the st module > > (if I use a modularized kernel). > this is the same which happens to me too using 2.1.119 to 122 > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542, > but I don't see it for DDS2 connected to NCR810. Am I imagining things, or isn't this a long-standing problem noted on Alan's "to-do" list? I don't know if Kai Makisara reads this list, so has anyone E-Mailed him directly with a report? Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sat Oct 10 12:02:40 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id MAA30798 for ; Sat, 10 Oct 1998 12:02:35 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id MAA13463 for ; Sat, 10 Oct 1998 12:02:04 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id MAA17329 for ; Sat, 10 Oct 1998 12:00:08 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id LAA16449; Sat, 10 Oct 1998 11:59:40 +0200 Received: by vger.rutgers.edu id <154198-2271>; Fri, 9 Oct 1998 23:13:58 -0400 Received: from news2.widomaker.com ([204.17.220.6]:4532 "HELO news2.widomaker.com" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with SMTP id <154318-2271>; Fri, 9 Oct 1998 20:59:45 -0400 Received: by news2.widomaker.com (Smail3.1.29.1 #1) id m0zRsSr-000G5cC; Sat, 10 Oct 98 02:25 EDT Received: from escape.widomaker.com (localhost [127.0.0.1]) by escape.widomaker.com (8.8.7/8.7.3) with ESMTP id CAA22812; Sat, 10 Oct 1998 02:10:20 -0400 Message-Id: <199810100610.CAA22812@escape.widomaker.com> To: "Steven N. Hirsch" cc: Harald Koenig , linux kernel list Subject: Re: Scsi tape - returns ENXIO after an error Reply-To: shendrix@escape.widomaker.com In-reply-to: Your message of "Fri, 09 Oct 1998 20:57:35 EDT." Date: Sat, 10 Oct 1998 02:10:20 -0400 From: Shannon Hendrix X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO In message , "Steven N. H irsch" writes: > On Fri, 9 Oct 1998, Harald Koenig wrote: > > > On Oct 09, Itai Nahshon wrote: > > > > > Hello, > > > I got a new DDS2 tape drive (Sony SDT-7000). I'm trying to read > > > an old tape (probably not compatible) and I'm getting this error: > > > > > > nahshon# tar vtf /dev/st0 > > > tar: Read error on /dev/st0: I/O error > > > tar: At beginning of tape, quitting now > > > > > > Later, I cannot use the tape drive: > > > > > > nahshon# tar vtf /dev/st0 > > > tar: Cannot open /dev/st0: No such device or address > > > > > > The only way to recover is to unload and reload the st module > > > (if I use a modularized kernel). > > > this is the same which happens to me too using 2.1.119 to 122 > > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542, > > but I don't see it for DDS2 connected to NCR810. > > Am I imagining things, or isn't this a long-standing problem noted on > Alan's "to-do" list? I don't know if Kai Makisara reads this list, so has > anyone E-Mailed him directly with a report? Just to add some noise... I had this problem in 2.1.10x. My system has a DPT 2044 SCSI controller and this exact problem occured with my Anaconda 4mm tape drive. Unloading and reloading the driver usually fixed things. I could only get a few hundred megs on tape before the driver died with a stream of timeout errors. Now I have 2.1.124 running and have done 2-6gb backups with no trouble (knock on wood). I have a Wangtek 5150ES Q250 drive that never worked since the pre-2.0 kernels and crashed the system in 2.1.107. It has never been tried with the current kernel (its not even hooked up). -- csh - shendrix@widomaker.com - http://www.widomaker.com - Will Hack 4 F00D ---------------------------------------------------------------------- "Work for something because it is good, not just because it stands a chance to succeed." -- Vaclav Havel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sun Oct 11 00:24:30 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id AAA01703 for ; Sun, 11 Oct 1998 00:24:29 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id AAA16359 for ; Sun, 11 Oct 1998 00:24:26 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id AAA26720 for ; Sun, 11 Oct 1998 00:22:39 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id AAA17742; Sun, 11 Oct 1998 00:22:01 +0200 Received: by vger.rutgers.edu id <154833-15794>; Sat, 10 Oct 1998 00:07:21 -0400 Received: from actcom.co.il ([192.114.47.1]:2562 "EHLO actcom.co.il" ident: "root") by vger.rutgers.edu with ESMTP id <156259-2271>; Fri, 9 Oct 1998 22:15:15 -0400 Received: from actcom.co.il by actcom.co.il with ESMTP (8.8.6/actcom-0.2) id JAA06473; Sat, 10 Oct 1998 09:53:10 +0200 (EET) (rfc931-sender: itai@i1-16.haifa4.actcom.co.il [192.114.80.234]) Message-ID: <361F0548.8D840C29@actcom.co.il> Date: Sat, 10 Oct 1998 09:57:12 +0300 From: Itai Nahshon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.124 i586) MIME-Version: 1.0 To: linux kernel list , Harald Koenig Subject: Re: Scsi tape - returns ENXIO after an error Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O > this is the same which happens to me too using 2.1.119 to 122 > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542, > but I don't see it for DDS2 connected to NCR810. > which SCSI controller are you using ? This is with Sony SDT-7000 drive connected to a AHA1542 controller. The problem did not repeat after I have over-written the tape thet caused it in the first place. IMHO, the problem is not related to the host adapter or the drive type. The drive returned an error and the SCSI error handling has set SDpnt->online = FALSE (why?). When trying to reopen the device scsi_block_when_processing_errors() returned FALSE. BTW, in 2.0.36-pre13 there was a 'st0: Incorrect block size.' kernel error message. Itai -- Itai Nahshon nahshon@actcom.co.il Also nahshon@vnet.ibm.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sun Oct 11 02:18:19 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA02646 for ; Sun, 11 Oct 1998 02:18:18 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA16689 for ; Sun, 11 Oct 1998 02:18:18 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id CAA28051 for ; Sun, 11 Oct 1998 02:16:49 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id CAA18176; Sun, 11 Oct 1998 02:16:20 +0200 Received: by vger.rutgers.edu id <154617-15794>; Sat, 10 Oct 1998 13:07:06 -0400 Received: from abies.metla.fi ([128.214.43.17]:4036 "EHLO abies.metla.fi" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <155089-15794>; Sat, 10 Oct 1998 01:42:33 -0400 Received: from localhost (makisara@localhost) by abies.metla.fi (8.8.5/8.8.5) with ESMTP id OAA03172; Sat, 10 Oct 1998 14:19:30 +0300 (EET DST) Date: Sat, 10 Oct 1998 14:19:30 +0300 (EET DST) From: Kai M{kisara Reply-To: Kai.Makisara@metla.fi To: "Steven N. Hirsch" cc: Harald Koenig , Itai Nahshon , linux kernel list , linux-scsi@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Fri, 9 Oct 1998, Steven N. Hirsch wrote: > > > On Fri, 9 Oct 1998, Harald Koenig wrote: > > > On Oct 09, Itai Nahshon wrote: > > > > > Hello, > > > I got a new DDS2 tape drive (Sony SDT-7000). I'm trying to read > > > an old tape (probably not compatible) and I'm getting this error: > > > > > > nahshon# tar vtf /dev/st0 > > > tar: Read error on /dev/st0: I/O error > > > tar: At beginning of tape, quitting now > > > > > > Later, I cannot use the tape drive: > > > > > > nahshon# tar vtf /dev/st0 > > > tar: Cannot open /dev/st0: No such device or address > > > > > > The only way to recover is to unload and reload the st module > > > (if I use a modularized kernel). > > > this is the same which happens to me too using 2.1.119 to 122 > > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542, > > but I don't see it for DDS2 connected to NCR810. > > Am I imagining things, or isn't this a long-standing problem noted on > Alan's "to-do" list? I don't know if Kai Makisara reads this list, so has > anyone E-Mailed him directly with a report? > I do read this list, although this is not the correct list for this problem (SCSI problems should be discussed on linux-scsi). I don't know what Alan means. I have done some investigations on the problem: - ENXIO is returned from some location in st.c, but I suspect that it comes from this: if( !scsi_block_when_processing_errors(scsi_tapes[dev].device) ) { return -ENXIO; } Could someone of you confirm this with a printk? If this is not the case, please forget that I wrote anything below this. The same piece of code is used also in the other high-level SCSI drivers. - scsi_block_when_processing_error(SDpnt) (in scsi_error.c) is essentially 'return SDpnt->online'. This flag is set when a SCSI device is detected and found to respond. The flag is not set anywhere else but it is reset in some locations in scsi_error.c (seems to be related situations where a device does not respond "correctly" after a bus or device reset). This explains that, if the reset fails, the device is gone until the driver is reloaded. If the theory above is correct, it explains why the device "disappears" after SCSI reset is performed by the middle-level driver. This leaves the question why the reset is being attempted. The timeouts the tape driver uses by default are very long. However, there are other timeouts in the SCSI protocol (on the signal level) and it may be that in some cases certain drives don't respond fast enough. One common reason for SCSI timeouts are the cables and/or termination. This may explain some resets but in most cases I have heard about the cables and termination seem to be OK. Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sun Oct 11 09:47:48 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id JAA04827 for ; Sun, 11 Oct 1998 09:47:48 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id JAA18589 for ; Sun, 11 Oct 1998 09:47:44 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id JAA03527 for ; Sun, 11 Oct 1998 09:46:17 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id JAA20277; Sun, 11 Oct 1998 09:45:52 +0200 Received: by vger.rutgers.edu id <156312-19981>; Sat, 10 Oct 1998 14:07:19 -0400 Received: from actcom.co.il ([192.114.47.1]:2922 "EHLO actcom.co.il" ident: "root") by vger.rutgers.edu with ESMTP id <157652-15794>; Sat, 10 Oct 1998 11:19:04 -0400 Received: from actcom.co.il by actcom.co.il with ESMTP (8.8.6/actcom-0.2) id WAA27027; Sat, 10 Oct 1998 22:53:44 +0200 (EET) (rfc931-sender: itai@i1-1.haifa4.actcom.co.il [192.114.80.220]) Message-ID: <361FBC36.FA64A3A4@actcom.co.il> Date: Sat, 10 Oct 1998 22:57:42 +0300 From: Itai Nahshon X-Mailer: Mozilla 4.05 [en] (X11; I; Linux 2.1.124 i586) MIME-Version: 1.0 To: Kai.Makisara@metla.fi CC: "Steven N. Hirsch" , Harald Koenig , linux kernel list , linux-scsi@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Kai M{kisara wrote: > > On Fri, 9 Oct 1998, Steven N. Hirsch wrote: > > > > > > > On Fri, 9 Oct 1998, Harald Koenig wrote: > > > > > On Oct 09, Itai Nahshon wrote: > > > > > > > Hello, > > > > I got a new DDS2 tape drive (Sony SDT-7000). I'm trying to read > > > > an old tape (probably not compatible) and I'm getting this error: > > > > > > > > nahshon# tar vtf /dev/st0 > > > > tar: Read error on /dev/st0: I/O error > > > > tar: At beginning of tape, quitting now > > > > > > > > Later, I cannot use the tape drive: > > > > > > > > nahshon# tar vtf /dev/st0 > > > > tar: Cannot open /dev/st0: No such device or address > > > > > > > > The only way to recover is to unload and reload the st module > > > > (if I use a modularized kernel). > > > > > this is the same which happens to me too using 2.1.119 to 122 > > > with SCSI tapes (DDS1 and QIC150) connected to an AHA1542, > > > but I don't see it for DDS2 connected to NCR810. > > > > Am I imagining things, or isn't this a long-standing problem noted on > > Alan's "to-do" list? I don't know if Kai Makisara reads this list, so has > > anyone E-Mailed him directly with a report? > > > I do read this list, although this is not the correct list for this > problem (SCSI problems should be discussed on linux-scsi). I don't know > what Alan means. > > I have done some investigations on the problem: > > - ENXIO is returned from some location in st.c, but I suspect that it > comes from this: > > if( !scsi_block_when_processing_errors(scsi_tapes[dev].device) ) { > return -ENXIO; > } > > Could someone of you confirm this with a printk? If this is not the case, > please forget that I wrote anything below this. > > The same piece of code is used also in the other high-level SCSI drivers. > > - scsi_block_when_processing_error(SDpnt) (in scsi_error.c) is essentially > 'return SDpnt->online'. This flag is set when a SCSI device is detected > and found to respond. The flag is not set anywhere else but it is reset in > some locations in scsi_error.c (seems to be related situations where a > device does not respond "correctly" after a bus or device reset). This > explains that, if the reset fails, the device is gone until the driver is > reloaded. I believe that's what happened. > > If the theory above is correct, it explains why the device "disappears" > after SCSI reset is performed by the middle-level driver. This leaves the > question why the reset is being attempted. The timeouts the tape driver > uses by default are very long. However, there are other timeouts in the SCSI > protocol (on the signal level) and it may be that in some cases certain > drives don't respond fast enough. One common reason for SCSI timeouts are > the cables and/or termination. This may explain some resets but in most > cases I have heard about the cables and termination seem to be OK. > > Kai There was no problem with the termination or physical connection. I just tried to read a tape which is probably in an incompatible format. Later I could write to that same tape and read back the new data. The tape with the wrong format gave a 'st0: Incorrect block size.' kernel error message when I tried it in 2.0.36-pre13. Itai -- Itai Nahshon nahshon@actcom.co.il Also nahshon@vnet.ibm.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Mon Oct 12 18:16:12 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA08735 for ; Mon, 12 Oct 1998 18:16:11 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id SAA14930 for ; Mon, 12 Oct 1998 18:17:37 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id SAA25665 for ; Mon, 12 Oct 1998 18:16:09 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id SAA30421; Mon, 12 Oct 1998 18:07:49 +0200 Received: by vger.rutgers.edu id <155106-7107>; Mon, 12 Oct 1998 04:35:43 -0400 Received: from mx03.uni-tuebingen.de ([134.2.3.13]:32526 "EHLO mx03.uni-tuebingen.de" ident: "root") by vger.rutgers.edu with ESMTP id <156361-7107>; Mon, 12 Oct 1998 02:39:16 -0400 Received: from alamak.tat.physik.uni-tuebingen.de (koenig@alamak.tat.physik.uni-tuebingen.de [134.2.170.66]) by mx03.uni-tuebingen.de (8.8.8/8.8.8) with ESMTP id OAA23727; Mon, 12 Oct 1998 14:34:44 +0200 Received: (from koenig@localhost) by alamak.tat.physik.uni-tuebingen.de (8.8.8/8.8.8) id OAA27546; Mon, 12 Oct 1998 14:34:24 +0200 Received: (from root@localhost) by turtle.tat.physik.uni-tuebingen.de (8.8.8/8.8.5) id LAA01351; Mon, 12 Oct 1998 11:55:49 +0200 Message-ID: <19981012115549.A623@tat.physik.uni-tuebingen.de> Date: Mon, 12 Oct 1998 11:55:49 +0200 From: Harald Koenig To: Kai.Makisara@metla.fi Cc: linux kernel list , linux-scsi@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error Mail-Followup-To: Kai.Makisara@metla.fi, linux kernel list , linux-scsi@vger.rutgers.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: ; from Kai M{kisara on Sat, Oct 10, 1998 at 02:19:30PM +0300 X-fingerprint: 3B CD 5A A9 73 44 DD 04 A0 4E A0 34 20 7B 1E 38 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Oct 10, Kai M{kisara wrote: > I have done some investigations on the problem: > > - ENXIO is returned from some location in st.c, but I suspect that it > comes from this: > > if( !scsi_block_when_processing_errors(scsi_tapes[dev].device) ) { > return -ENXIO; > } > > Could someone of you confirm this with a printk? If this is not the case, > please forget that I wrote anything below this. I replaced every return (-E....) by RETURN (...) and used #define RETURN(r) do { printk("--> st:RETURN %d in line %d\n",r,__LINE__); return (r); } while (0) (so line number are off by one for 2.1.125) and when trying to read past EOF/EOT for QIC150 I got: ------------------------------------------------------------------------------- st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). aha1542.c: Trying device reset for target 2 Sent BUS RESET to scsi host 1 st0: Error: 8000002, cmd: 8 1 0 0 40 0 Len: 32768 extra data not valid Current error st09:00: sense key Unit Attention Additional sense indicates Power on, reset, or bus device reset occurred --> st:RETURN -5 in line 217 st0: Sense: 70 0 6 0 0 0 0 16 st0: Tape error while reading. ------------------------------------------------------------------------------- which is the RETURN (-EIO) at the very end of st_chk_result() in line 216. no other error returns show up in st.c. note that the `aha1542.c: Trying device reset...' shows up before any debug message from st.c or error in st.c Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Tue Oct 13 07:15:22 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id HAA15013 for ; Tue, 13 Oct 1998 07:15:22 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.8.7/8.8.5) with ESMTP id HAA26086 for ; Tue, 13 Oct 1998 07:15:22 +0200 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id HAA19144 for ; Tue, 13 Oct 1998 07:13:57 +0200 (MET DST) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id GAA01810; Tue, 13 Oct 1998 06:43:30 +0200 Received: by vger.rutgers.edu id <156328-7107>; Mon, 12 Oct 1998 15:29:14 -0400 Received: from abies.metla.fi ([128.214.43.17]:4630 "EHLO abies.metla.fi" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <156475-7107>; Mon, 12 Oct 1998 09:56:52 -0400 Received: from localhost (makisara@localhost) by abies.metla.fi (8.8.5/8.8.5) with ESMTP id WAA04897; Mon, 12 Oct 1998 22:56:09 +0300 (EET DST) Date: Mon, 12 Oct 1998 22:56:09 +0300 (EET DST) From: Kai M{kisara Reply-To: Kai.Makisara@metla.fi To: Harald Koenig cc: linux kernel list , linux-scsi@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error In-Reply-To: <19981012115549.A623@tat.physik.uni-tuebingen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Mon, 12 Oct 1998, Harald Koenig wrote: > On Oct 10, Kai M{kisara wrote: > ... > I replaced every return (-E....) by RETURN (...) and used > > #define RETURN(r) do { printk("--> st:RETURN %d in line %d\n",r,__LINE__); return (r); } while (0) > > (so line number are off by one for 2.1.125) and when trying to read > past EOF/EOT for QIC150 I got: > ------------------------------------------------------------------------------- > st0: Block limits 512 - 512 bytes. > st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 > st0: Density 0, tape length: 0, drv buffer: 1 > st0: Block size: 512, buffer size: 32768 (64 blocks). > aha1542.c: Trying device reset for target 2 > Sent BUS RESET to scsi host 1 > st0: Error: 8000002, cmd: 8 1 0 0 40 0 Len: 32768 > extra data not valid Current error st09:00: sense key Unit Attention > Additional sense indicates Power on, reset, or bus device reset occurred > --> st:RETURN -5 in line 217 > st0: Sense: 70 0 6 0 0 0 0 16 > st0: Tape error while reading. > ------------------------------------------------------------------------------- > > which is the RETURN (-EIO) at the very end of st_chk_result() in line 216. > no other error returns show up in st.c. > This is actually the correct thing to return. Unit Attention sense data is returned from the first command after the device is reset. Many drives rewind the tape when reset and it is best to signal an error so that the user can make sure that the tape is in the correct location. Actually, the middle-level SCSI driver sets a flag (was_reset) so that the tape driver does not allow any more commands until the user does something that explicitly positions the tape to a known position. If the drive disappears after the reset, that is a bug (somewhere). > > note that the `aha1542.c: Trying device reset...' shows up before any > debug message from st.c or error in st.c > The driver has printed several debug messages from scsi_tape_open(). The command attempted before reset was trying to read 64 blocks of fixed length (512 bytes) from the tape. Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From linux@muni.cz Thu Oct 22 21:10:22 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id VAA30363; Thu, 22 Oct 1998 21:10:21 +0200 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id VAA31927; Thu, 22 Oct 1998 21:10:21 +0200 Received: from dior.ics.muni.cz (dior.ics.muni.cz [147.251.6.10]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id VAA23261; Thu, 22 Oct 1998 21:09:54 +0200 (MET DST) Received: from dior.ics.muni.cz (localhost [127.0.0.1]) by dior.ics.muni.cz (8.8.5/8.8.5) with SMTP id VAA23238; Thu, 22 Oct 1998 21:09:50 +0200 (MEST) Date: Thu, 22 Oct 1998 21:09:50 +0200 (MEST) Message-Id: <70nuqc$88e$1@adis.cesnet.cz> Errors-To: kas@informatics.muni.cz Reply-To: linux@muni.cz Originator: linux@muni.cz Sender: linux@muni.cz Precedence: bulk From: xpalo03@vse.cz (Ondrej Palkovsky) To: Multiple recipients of list Subject: Re: Tape filesystem X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas X-Comment: Diskuse o operacnim systemu Linux Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Mime-Version: 1.0 Status: RO In article <362E0DDC.6262B10A@kva.pvt.cz>, davidpos@kva.pvt.cz (David Pospisilik) writes: > Zdravim, > nevite nekdo o nejakym softu, diky kterymu bych mohl na pasku > pristupovat jako na Block-device ?? > V kernel 2.2 wishlist je sice odkaz nekam do nemecka, ze tam nekdo delal > TFS (tusim jako minix fs), ale na onoho cloveka uz uvedeny kontakt > neplati. > hmm, nevim kde jsem to sebral, ale mam tady na stole: wormdat-1.1-1.RPM for i386 Vendor: jhpb@sarto.gaithersburg.md.us Summary: NFS Server for WangDAT 2000 SCSI tape drive .. ale mozna to bude chodit i s necim jinym -- Goto, n.: A programming tool that exists to allow structured programmers to complain about unstructured programmers. -- Ray Simard From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Nov 11 21:59:10 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id VAA18162 for ; Wed, 11 Nov 1998 21:59:09 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id VAA24944 for ; Wed, 11 Nov 1998 21:59:19 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id VAA25957 for ; Wed, 11 Nov 1998 21:58:52 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id VAA29174; Wed, 11 Nov 1998 21:57:34 +0100 Received: by vger.rutgers.edu id <154974-19402>; Wed, 11 Nov 1998 12:33:54 -0500 Received: from canopus.estinc.com ([209.140.128.15]:22072 "EHLO canopus.estinc.com" ident: "root") by vger.rutgers.edu with ESMTP id <154106-19402>; Wed, 11 Nov 1998 10:15:55 -0500 Received: from estinc.com (rjf@nile.inhouse [192.168.0.31]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id IAA08666 for ; Wed, 11 Nov 1998 08:33:15 -0700 Message-ID: <3649ADCF.87BC328A@estinc.com> Date: Wed, 11 Nov 1998 08:31:27 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] Content-Type: multipart/mixed; boundary="------------8D5CB9FFF7C338E2E58800CD" X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: RO This is a multi-part message in MIME format. --------------8D5CB9FFF7C338E2E58800CD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Some weeks ago, there was discussion on linux-kernel about a problem with SCSI tape drives connected to a 1542 being put offline after any kind of error. Since it still occurs in the 2.1.127 kernel, I'm assuming there was no fix for this. My understanding of the problem is this: On any failure, the 1542 driver calls the scsi error handling code, which attempts a series of device, bus, an adapter resets and retries to try and clear the "failure". If the command still fails, the device is taken offline, resulting in ENXIO being returned in any subsequent attempts to access the device. Generally, this is acceptable, because you don't want a single mis-behaving device to hang the whole system. But with tape drives, there are certain "failures" that should be considered "normal" - particularly reaching EOM while writing, or a filemark (FMK) while reading.. Assuming that my understanding of the problem is correct, I have attached a patch that suppresses the error handling code if the sense data indicates EOM or FMK. Please let me know if this breaks anything, or if there is some other reason not to include it in the kernel. -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com --------------8D5CB9FFF7C338E2E58800CD Content-Type: text/plain; charset=us-ascii; name="aha1542-patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="aha1542-patch" --- aha1542.c.old Wed Nov 11 08:27:11 1998 +++ aha1542.c Wed Nov 11 08:28:06 1998 @@ -18,6 +18,9 @@ * 1-Jan-97 * Modified by Bjorn L. Thordarson and Einar Thor Einarsson * Recognize that DMA0 is valid DMA channel -- 13-Jul-98 + * Modified by Richard Fish + * Suppress reset/retry error handling at EOM/EOF conditions + * 11-Nov-98 */ #include @@ -242,6 +245,8 @@ switch (hosterr) { case 0x0: case 0xa: /* Linked command complete without error and linked normally */ + break; + case 0xb: /* Linked command complete without error, interrupt generated */ hosterr = 0; break; @@ -487,12 +492,19 @@ /* is there mail :-) */ /* more error checking left out here */ - if (mbistatus != 1) - /* This is surely wrong, but I don't know what's right */ - errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); - else + if (mbistatus != 1) { + /* RJF - catch for EOM/EOF -- not really an error so we don't want the error + handler to run */ + if (SCtmp->sense_buffer[2] & 0x40 || SCtmp->sense_buffer[2] & 0x80) { + errstatus = makecode(DID_PASSTHROUGH, ccb[mbo].tarstat); + } else { + /* This is surely wrong, but I don't know what's right */ + errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); + } + } else { errstatus = 0; - + } + #ifdef DEBUG if(errstatus) printk("(aha1542 error:%x %x %x) ",errstatus, ccb[mbo].hastat, ccb[mbo].tarstat); --------------8D5CB9FFF7C338E2E58800CD-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Thu Nov 12 13:40:35 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id NAA29396 for ; Thu, 12 Nov 1998 13:40:34 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id NAA11419 for ; Thu, 12 Nov 1998 13:40:33 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id NAA24805 for ; Thu, 12 Nov 1998 13:40:07 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id NAA06370; Thu, 12 Nov 1998 13:38:36 +0100 Received: by vger.rutgers.edu id <155065-28307>; Thu, 12 Nov 1998 05:48:11 -0500 Received: from mx01.uni-tuebingen.de ([134.2.3.11]:18990 "EHLO mx01.uni-tuebingen.de" ident: "root") by vger.rutgers.edu with ESMTP id <155559-28307>; Thu, 12 Nov 1998 05:29:33 -0500 Received: from alamak.tat.physik.uni-tuebingen.de (koenig@alamak.tat.physik.uni-tuebingen.de [134.2.170.66]) by mx01.uni-tuebingen.de (8.8.8/8.8.8) with ESMTP id LAA05398; Thu, 12 Nov 1998 11:47:11 +0100 Received: (from koenig@localhost) by alamak.tat.physik.uni-tuebingen.de (8.8.8/8.8.8) id LAA13558; Thu, 12 Nov 1998 11:47:04 +0100 Received: (from root@localhost) by turtle.tat.physik.uni-tuebingen.de (8.8.8/8.8.5) id LAA00565; Thu, 12 Nov 1998 11:45:21 +0100 Message-ID: <19981112114520.A338@tat.physik.uni-tuebingen.de> Date: Thu, 12 Nov 1998 11:45:20 +0100 From: Harald Koenig To: Richard Fish , linux-kernel@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] Mail-Followup-To: Richard Fish , linux-kernel@vger.rutgers.edu References: <3649ADCF.87BC328A@estinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.1i In-Reply-To: <3649ADCF.87BC328A@estinc.com>; from Richard Fish on Wed, Nov 11, 1998 at 08:31:27AM -0700 X-fingerprint: 3B CD 5A A9 73 44 DD 04 A0 4E A0 34 20 7B 1E 38 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Nov 11, Richard Fish wrote: > Some weeks ago, there was discussion on linux-kernel about a problem > with SCSI tape drives connected to a 1542 being put offline after any > kind of error. Since it still occurs in the 2.1.127 kernel, I'm > assuming there was no fix for this. thanks! I just tried your patch with 2.1.126 (since 2.1.127 frequently locks up for me in scheduler). it seems to fix only half of the problem, but the more important half;) the failure at FMK is gone, but reading at EOM still resets the bus: I'm using a QIC150 drive with only one tar archive stored on the tape. the first read using tar tvRi works fine, stops at EOF with no error nor bus reset. but when I try to read again using the same tar command (there might be a 2nd archive on the tape) I still get a scsi bus reset. here is the debug output of st driver: st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 0, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Error: 8000002, cmd: 8 1 0 0 40 0 Len: 32768 FMK Current error st09:00: sense key None Additional sense indicates Filemark detected st0: Sense: f0 0 80 0 0 0 3c 16 st0: EOF detected (2048 bytes read). st0: EOF up (1). Left 2048, needed 2048. st0: EOF/EOM flag up (1). Bytes 0 st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 10, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 10, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: Got tape pos. blk 5063 part 0. st0: Block limits 512 - 512 bytes. st0: Mode sense. Length 11, medium 6, WBS 10, BLL 8 st0: Density 10, tape length: 0, drv buffer: 1 st0: Block size: 512, buffer size: 32768 (64 blocks). st0: EOF/EOM flag up (2). Bytes 0 aha1542.c: Trying device reset for target 2 Sent BUS RESET to scsi host 1 st0: Error: 8000002, cmd: 8 1 0 0 40 0 Len: 32768 extra data not valid Current error st09:00: sense key Unit Attention Additional sense indicates Power on, reset, or bus device reset occurred st0: Sense: 70 0 6 0 0 0 0 16 st0: Tape error while reading. > My understanding of the problem is this: > > On any failure, the 1542 driver calls the scsi error handling code, > which attempts a series of device, bus, an adapter resets and retries to > try and clear the "failure". If the command still fails, the device is > taken offline, resulting in ENXIO being returned in any subsequent > attempts to access the device. Generally, this is acceptable, because > you don't want a single mis-behaving device to hang the whole system. > > But with tape drives, there are certain "failures" that should be > considered "normal" - particularly reaching EOM while writing, or a > filemark (FMK) while reading.. > > Assuming that my understanding of the problem is correct, I have > attached a patch that suppresses the error handling code if the sense > data indicates EOM or FMK. Please let me know if this breaks anything, > or if there is some other reason not to include it in the kernel. > > -- > Richard Fish Enhanced Software Technologies, Inc. > Software Developer 4014 E Broadway Rd Suite 405 > rjf@estinc.com Phoenix, AZ 85040 > (602) 470-1115 http://www.estinc.com > --- aha1542.c.old Wed Nov 11 08:27:11 1998 > +++ aha1542.c Wed Nov 11 08:28:06 1998 > @@ -18,6 +18,9 @@ > * 1-Jan-97 > * Modified by Bjorn L. Thordarson and Einar Thor Einarsson > * Recognize that DMA0 is valid DMA channel -- 13-Jul-98 > + * Modified by Richard Fish > + * Suppress reset/retry error handling at EOM/EOF conditions > + * 11-Nov-98 > */ > > #include > @@ -242,6 +245,8 @@ > switch (hosterr) { > case 0x0: > case 0xa: /* Linked command complete without error and linked normally */ > + break; > + > case 0xb: /* Linked command complete without error, interrupt generated */ > hosterr = 0; > break; > @@ -487,12 +492,19 @@ > /* is there mail :-) */ > > /* more error checking left out here */ > - if (mbistatus != 1) > - /* This is surely wrong, but I don't know what's right */ > - errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); > - else > + if (mbistatus != 1) { > + /* RJF - catch for EOM/EOF -- not really an error so we don't want the error > + handler to run */ > + if (SCtmp->sense_buffer[2] & 0x40 || SCtmp->sense_buffer[2] & 0x80) { > + errstatus = makecode(DID_PASSTHROUGH, ccb[mbo].tarstat); > + } else { > + /* This is surely wrong, but I don't know what's right */ > + errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); > + } > + } else { > errstatus = 0; > - > + } > + > #ifdef DEBUG > if(errstatus) printk("(aha1542 error:%x %x %x) ",errstatus, > ccb[mbo].hastat, ccb[mbo].tarstat); Harald -- All SCSI disks will from now on ___ _____ be required to send an email notice 0--,| /OOOOOOO\ 24 hours prior to complete hardware failure! <_/ / /OOOOOOOOOOO\ \ \/OOOOOOOOOOOOOOO\ \ OOOOOOOOOOOOOOOOO|// Harald Koenig, \/\/\/\/\/\/\/\/\/ Inst.f.Theoret.Astrophysik // / \\ \ koenig@tat.physik.uni-tuebingen.de ^^^^^ ^^^^^ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Fri Nov 13 02:25:05 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA11915 for ; Fri, 13 Nov 1998 02:25:05 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id CAA08393 for ; Fri, 13 Nov 1998 02:25:04 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id CAA17326 for ; Fri, 13 Nov 1998 02:24:39 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id CAA11836; Fri, 13 Nov 1998 02:24:21 +0100 Received: by vger.rutgers.edu id <155265-28307>; Thu, 12 Nov 1998 18:18:54 -0500 Received: from canopus.estinc.com ([209.140.128.15]:5242 "EHLO canopus.estinc.com" ident: "root") by vger.rutgers.edu with ESMTP id <156300-28307>; Thu, 12 Nov 1998 16:49:26 -0500 Received: from estinc.com (rjf@nile.inhouse [192.168.0.31]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id PAA29537 for ; Thu, 12 Nov 1998 15:12:44 -0700 Message-ID: <364B5CBF.CE0C39C2@estinc.com> Date: Thu, 12 Nov 1998 15:10:07 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] Content-Type: multipart/mixed; boundary="------------AFA7F7C6C9DFB65060BEA465" X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O This is a multi-part message in MIME format. --------------AFA7F7C6C9DFB65060BEA465 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, my brain really wasn't working very well when I sent this, because I also meant it to go the linux-kernel list... -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com --------------AFA7F7C6C9DFB65060BEA465 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from nile.inhouse (rjf@nile.inhouse [192.168.0.31]) by nile.inhouse (8.8.7/8.8.7) with ESMTP id OAA00808 for ; Thu, 12 Nov 1998 14:30:04 -0700 Received: from dbserv by nile.inhouse (fetchmail-4.5.3 POP3) for (single-drop); Thu, 12 Nov 1998 14:30:04 MST Received: from canopus.estinc.com (IDENT:root@canopus.inhouse [192.168.0.1]) by dbserv.inhouse (8.9.0/8.9.0) with ESMTP id VAA22678 for ; Thu, 12 Nov 1998 21:15:59 GMT Received: from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id OAA29453 for ; Thu, 12 Nov 1998 14:28:04 -0700 Received: from vger.rutgers.edu ([128.6.190.2]:27762 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <8581-28602>; Thu, 12 Nov 1998 23:22:25 +0200 Received: by vger.rutgers.edu id <154351-28307>; Thu, 12 Nov 1998 14:29:42 -0500 Received: from canopus.estinc.com ([209.140.128.15]:4145 "EHLO canopus.estinc.com" ident: "root") by vger.rutgers.edu with ESMTP id <154330-28307>; Thu, 12 Nov 1998 13:21:30 -0500 Received: from estinc.com (rjf@nile.inhouse [192.168.0.31]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id LAA29114; Thu, 12 Nov 1998 11:44:09 -0700 Message-ID: <364B2BCA.E4AAC038@estinc.com> Date: Thu, 12 Nov 1998 11:41:14 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-scsi@vger.rutgers.edu CC: Harald Koenig , Peter Waltenberg Subject: Re: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] References: <3649ADCF.87BC328A@estinc.com> <19981112114520.A338@tat.physik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orcpt: rfc822;linux-scsi@vger.rutgers.edu Sender: owner-linux-scsi@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Ok, here is my second attempt. This patch will need to be applied to the original aha1542.c file, so be sure to either back out the last patch or extract an original aha1542.c from the kernel source. Basically, now if the device is a tape drive and the result byte looks like something that st should be able to handle, we'll just pass the error up to st. Harald Koenig wrote: > > On Nov 11, Richard Fish wrote: > > > Some weeks ago, there was discussion on linux-kernel about a problem > > with SCSI tape drives connected to a 1542 being put offline after any > > kind of error. Since it still occurs in the 2.1.127 kernel, I'm > > assuming there was no fix for this. > > thanks! I just tried your patch with 2.1.126 (since 2.1.127 frequently > locks up for me in scheduler). it seems to fix only half of the problem, > but the more important half;) -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.rutgers.edu   --------------AFA7F7C6C9DFB65060BEA465-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Fri Nov 13 02:30:47 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id CAA11933 for ; Fri, 13 Nov 1998 02:30:46 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id CAA28408 for ; Fri, 13 Nov 1998 02:30:45 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id CAA17436 for ; Fri, 13 Nov 1998 02:30:20 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id CAA11872; Fri, 13 Nov 1998 02:29:25 +0100 Received: by vger.rutgers.edu id <155272-28307>; Thu, 12 Nov 1998 18:19:54 -0500 Received: from canopus.estinc.com ([209.140.128.15]:5244 "EHLO canopus.estinc.com" ident: "root") by vger.rutgers.edu with ESMTP id <156341-28307>; Thu, 12 Nov 1998 16:51:14 -0500 Received: from estinc.com (rjf@nile.inhouse [192.168.0.31]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id PAA29543 for ; Thu, 12 Nov 1998 15:13:56 -0700 Message-ID: <364B5D08.DE272428@estinc.com> Date: Thu, 12 Nov 1998 15:11:20 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] Content-Type: multipart/mixed; boundary="------------C59B75A1474C264A691CFAFC" X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O This is a multi-part message in MIME format. --------------C59B75A1474C264A691CFAFC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, my brain really wasn't working very well when I sent this, because I also meant it to go the linux-kernel list... -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com --------------C59B75A1474C264A691CFAFC Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: Received: from nile.inhouse (rjf@nile.inhouse [192.168.0.31]) by nile.inhouse (8.8.7/8.8.7) with ESMTP id OAA00810 for ; Thu, 12 Nov 1998 14:30:04 -0700 Received: from dbserv by nile.inhouse (fetchmail-4.5.3 POP3) for (single-drop); Thu, 12 Nov 1998 14:30:04 MST Received: from canopus.estinc.com (IDENT:root@canopus.inhouse [192.168.0.1]) by dbserv.inhouse (8.9.0/8.9.0) with ESMTP id VAA22684 for ; Thu, 12 Nov 1998 21:16:02 GMT Received: from listserv.funet.fi (listserv.funet.fi [128.214.248.27]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id OAA29456 for ; Thu, 12 Nov 1998 14:28:06 -0700 Received: from vger.rutgers.edu ([128.6.190.2]:27762 "EHLO vger.rutgers.edu" ident: "NO-IDENT-SERVICE[2]") by listserv.funet.fi with ESMTP id <8475-31466>; Thu, 12 Nov 1998 23:23:39 +0200 Received: by vger.rutgers.edu id <154330-28307>; Thu, 12 Nov 1998 14:30:00 -0500 Received: from canopus.estinc.com ([209.140.128.15]:4161 "EHLO canopus.estinc.com" ident: "root") by vger.rutgers.edu with ESMTP id <154332-28307>; Thu, 12 Nov 1998 13:24:40 -0500 Received: from estinc.com (rjf@nile.inhouse [192.168.0.31]) by canopus.estinc.com (8.8.7/8.8.7) with ESMTP id LAA29142; Thu, 12 Nov 1998 11:47:34 -0700 Message-ID: <364B2C98.B67D5644@estinc.com> Date: Thu, 12 Nov 1998 11:44:40 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-scsi@vger.rutgers.edu CC: Harald Koenig , Peter Waltenberg Subject: [Fwd: Scsi tape - returns ENXIO after an error (aha1542) [PATCH]] Content-Type: multipart/mixed; boundary="------------BB5C540CCFC8E71A7E19CB77" X-Orcpt: rfc822;linux-scsi@vger.rutgers.edu Sender: owner-linux-scsi@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu This is a multi-part message in MIME format. --------------BB5C540CCFC8E71A7E19CB77 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ooops. Here is the new patch... -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com --------------BB5C540CCFC8E71A7E19CB77 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Mozilla-Status2: 00000000 Message-ID: <364B2BCA.E4AAC038@estinc.com> Date: Thu, 12 Nov 1998 11:41:14 -0700 From: Richard Fish X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.1.127 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-scsi@vger.rutgers.edu CC: Harald Koenig , Peter Waltenberg Subject: Re: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] References: <3649ADCF.87BC328A@estinc.com> <19981112114520.A338@tat.physik.uni-tuebingen.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ok, here is my second attempt. This patch will need to be applied to the original aha1542.c file, so be sure to either back out the last patch or extract an original aha1542.c from the kernel source. Basically, now if the device is a tape drive and the result byte looks like something that st should be able to handle, we'll just pass the error up to st. Harald Koenig wrote: > > On Nov 11, Richard Fish wrote: > > > Some weeks ago, there was discussion on linux-kernel about a problem > > with SCSI tape drives connected to a 1542 being put offline after any > > kind of error. Since it still occurs in the 2.1.127 kernel, I'm > > assuming there was no fix for this. > > thanks! I just tried your patch with 2.1.126 (since 2.1.127 frequently > locks up for me in scheduler). it seems to fix only half of the problem, > but the more important half;) -- Richard Fish Enhanced Software Technologies, Inc. Software Developer 4014 E Broadway Rd Suite 405 rjf@estinc.com Phoenix, AZ 85040 (602) 470-1115 http://www.estinc.com --------------BB5C540CCFC8E71A7E19CB77 Content-Type: text/plain; charset=us-ascii; name="aha1542-patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="aha1542-patch" --- aha1542.c.old Wed Oct 7 15:52:55 1998 +++ aha1542.c Thu Nov 12 11:31:48 1998 @@ -18,6 +18,10 @@ * 1-Jan-97 * Modified by Bjorn L. Thordarson and Einar Thor Einarsson * Recognize that DMA0 is valid DMA channel -- 13-Jul-98 + * Modified by Richard Fish + * Suppress reset/retry error handling code for tape drives + * for various events like EOF, EOM, EOD, etc... + * 11-Nov-1998 */ #include @@ -242,6 +246,8 @@ switch (hosterr) { case 0x0: case 0xa: /* Linked command complete without error and linked normally */ + break; + case 0xb: /* Linked command complete without error, interrupt generated */ hosterr = 0; break; @@ -487,12 +493,24 @@ /* is there mail :-) */ /* more error checking left out here */ - if (mbistatus != 1) - /* This is surely wrong, but I don't know what's right */ - errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); - else + if (mbistatus != 1) { + /* RJF - suppress error handler for tape drives when the status + is GOOD or CHECK_CONDITION. This will hopefully allow EOM, EOF, etc + "failures" to be reported to the st driver, which is better + suited to handling these... */ + /* NOTE - why does mbistatus != 1 when the command result is GOOD? */ + if (SCtmp->device->type == TYPE_TAPE && + ((status_byte(SCtmp->result) == GOOD) || + (status_byte(SCtmp->result) & CHECK_CONDITION))) { + errstatus = makecode(DID_PASSTHROUGH, ccb[mbo].tarstat); + } else { + /* This is surely wrong, but I don't know what's right */ + errstatus = makecode(ccb[mbo].hastat, ccb[mbo].tarstat); + } + } else { errstatus = 0; - + } + #ifdef DEBUG if(errstatus) printk("(aha1542 error:%x %x %x) ",errstatus, ccb[mbo].hastat, ccb[mbo].tarstat); --------------BB5C540CCFC8E71A7E19CB77-- - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@vger.rutgers.edu   --------------C59B75A1474C264A691CFAFC-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Fri Nov 13 10:06:41 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id KAA15490 for ; Fri, 13 Nov 1998 10:06:36 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id KAA28121 for ; Fri, 13 Nov 1998 10:06:35 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id KAA06308 for ; Fri, 13 Nov 1998 10:06:11 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id KAA14784; Fri, 13 Nov 1998 10:05:23 +0100 Received: by vger.rutgers.edu id <153901-32375>; Fri, 13 Nov 1998 03:31:28 -0500 Received: from bill.zdv.Uni-Mainz.DE ([134.93.8.148]:41244 "EHLO bill.zdv.Uni-Mainz.DE" ident: "kubla") by vger.rutgers.edu with ESMTP id <154311-32375>; Fri, 13 Nov 1998 02:53:40 -0500 Received: (from kubla@localhost) by bill.zdv.Uni-Mainz.DE (8.8.8/8.8.8) id JAA20060 for linux-kernel@vger.rutgers.edu; Fri, 13 Nov 1998 09:16:16 +0100 (MET) Message-ID: <19981113091616.A20050@zdv.Uni-Mainz.DE> Date: Fri, 13 Nov 1998 09:16:16 +0100 From: Dominik Kubla To: linux-kernel@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error (aha1542) [PATCH] References: <3649ADCF.87BC328A@estinc.com> <199811121728.MAA26701@escape.widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93i In-Reply-To: <199811121728.MAA26701@escape.widomaker.com>; from C S Hendrix on Thu, Nov 12, 1998 at 12:28:25PM -0500 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O On Thu, Nov 12, 1998 at 12:28:25PM -0500, C S Hendrix wrote: > In message <3649ADCF.87BC328A@estinc.com>, Richard Fish writes: [...] > > My understanding of the problem is this: > [snip] > > I think it is VERY important that people realize this problem is > NOT limited to the systems with 154x controllers. > > My system with a DPT 2044W is also failing when accessing the tape > drive. Something happened regarding tape support between 2.0 and > 2.1 kernels. I have had to fall back to 2.0.35 because I cannot > get reliable tape operation in 2.1.x. Same here with a Multia and its onboard NCR 810 controller: I can use the tape exactly one time. Then i need to reboot... Dominik Kubla -- The text above represents my personal opinion and does not represent the official position of my employer on the issue(s) discussed. Any official statement by me on behalf of my employer will be marked as such. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Sat Nov 14 22:41:07 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id WAA15139 for ; Sat, 14 Nov 1998 22:41:06 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id WAA10155 for ; Sat, 14 Nov 1998 22:41:05 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id WAA24755 for ; Sat, 14 Nov 1998 22:40:43 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id WAA26431; Sat, 14 Nov 1998 22:40:08 +0100 Received: by vger.rutgers.edu id <156549-5740>; Sat, 14 Nov 1998 13:59:43 -0500 Received: from abies.metla.fi ([128.214.43.17]:2472 "EHLO abies.metla.fi" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <156342-5740>; Sat, 14 Nov 1998 13:44:40 -0500 Received: from localhost (makisara@localhost) by abies.metla.fi (8.8.5/8.8.5) with ESMTP id JAA29674; Sat, 14 Nov 1998 09:25:20 +0200 (EET) Date: Sat, 14 Nov 1998 09:25:20 +0200 (EET) From: Kai M{kisara Reply-To: Kai.Makisara@metla.fi To: Richard Fish cc: linux-kernel@vger.rutgers.edu, linux-scsi@vger.rutgers.edu Subject: Re: Scsi tape - returns ENXIO after an error (aha1542 + others) [PATCH] In-Reply-To: <364C6B6E.81E7FF5D@estinc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O This is sent to linux-kernel only because it replies a message sent there. We really should keep this discussion in linux-scsi! On Fri, 13 Nov 1998, Richard Fish wrote: > C S Hendrix wrote: > > In message <3649ADCF.87BC328A@estinc.com>, Richard Fish writes: ... > [snip] > > > Is there a way to do this in a way that is not specific to the SCSI > > controller driver? Or would each low-level driver have to receive > > a similar patch? > > Ok, here is a patch to scsi_error.c that will hopefully fix the problem > for all controllers. This removes the need for a patch to aha1542.c. > Please test and let me know if there are any problems. > >--- scsi_error.c.old Mon Jul 27 18:21:59 1998 >+++ scsi_error.c Fri Nov 13 08:42:21 1998 >@@ -945,6 +945,18 @@ > } > > /* >+ * For tape drives, pass common failures to high-level driver >+ */ >+ if( SCpnt->device->type == TYPE_TAPE && >+ (status_byte(SCpnt->result) == GOOD) || >+ (status_byte(SCpnt->result) & CHECK_CONDITION)) >+ { >+ SCpnt->result &= 0xff00ffff; >+ return SUCCESS; >+ } Your patch practically bypasses the error handling for tapes and this is not correct. It would be better to selectively fix the error responses that cause problems. I don't have any SCSI adapter that uses the new error handling and so the following is just speculation. The function scsi_check_sense() returns SUCCESS in case of UNIT_ATTENTION and the comment says that in this case the the information is passed up to the upper level driver. This is what want to happen with FM, EOM, and ILI. If the test near the beginning of the function is changed to if (SCpnt->sense_buffer[2] & 0xe0) return FAILED; it might help. In addition to the condition bits, the tape driver needs to get up the information about BLANK_CHECK. Before even thinking to add something like this to the kernel, someone should check what the result would be for the whole middle-level SCSI system, taking into account all device types. Kai - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From owner-linux-kernel-outgoing@vger.rutgers.edu Wed Dec 9 23:42:36 1998 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id XAA11070 for ; Wed, 9 Dec 1998 23:42:36 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id XAA04116 for ; Wed, 9 Dec 1998 23:42:35 +0100 Received: from morlor.karlin.mff.cuni.cz (root@morlor.karlin.mff.cuni.cz [195.113.30.2]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with ESMTP id XAA10473 for ; Wed, 9 Dec 1998 23:42:46 +0100 (MET) Received: from vger.rutgers.edu (vger.rutgers.edu [128.6.190.2]) by morlor.karlin.mff.cuni.cz (8.8.8/8.8.8) with ESMTP id XAA18162; Wed, 9 Dec 1998 23:38:43 +0100 Received: by vger.rutgers.edu id <154617-219>; Wed, 9 Dec 1998 06:24:59 -0500 Received: from chaos.analogic.com ([204.178.40.224]:1095 "EHLO chaos.analogic.com" ident: "SOCKWRITE-65") by vger.rutgers.edu with ESMTP id <156898-219>; Tue, 8 Dec 1998 22:44:47 -0500 Received: (from root@localhost) by chaos.analogic.com (8.7.5/8.7.3) id DAA00879; Wed, 9 Dec 1998 03:43:11 GMT Date: Tue, 8 Dec 1998 22:43:11 -0500 (EST) From: "Richard B. Johnson" Reply-To: root@chaos.analogic.com To: Linux kernel Subject: SCSI Tape on Linux 2.1.131 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Status: O Hello SCSI Tape persons! If I get a media error on a SCSI Tape (pretty common with Exabyte drives), when using tar to back-up a file-system, the process goes into "down_failed" and can't be killed. The tape-drive remains "busy" and can't be reused without a re-boot. I thought this problem was fixed about a year ago. It's now back. Cheers, Dick Johnson ***** FILE SYSTEM WAS MODIFIED ***** Penguin : Linux version 2.1.131 on an i686 machine (400.59 BogoMips). Warning : It's hard to remain at the trailing edge of technology. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/ From linux-return-33542-letty=mrakoplas.phil.muni.cz@linux.cz Mon Jan 25 13:08:33 1999 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id NAA27061 for ; Mon, 25 Jan 1999 13:08:32 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id NAA00673 for ; Mon, 25 Jan 1999 13:08:31 +0100 Received: from odysseus.linux.cz (kwKjVYdsIL9QUO11n4cm16SgvqpCMRcn@[147.251.48.205]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with SMTP id NAA28118 for ; Mon, 25 Jan 1999 13:08:13 +0100 (MET) Received: (qmail 479 invoked by uid 30); 25 Jan 1999 12:07:05 -0000 Mailing-List: contact linux-help@linux.cz; run by ezmlm Precedence: bulk Reply-To: linux@linux.cz Delivered-To: mailing list linux@linux.cz Received: (qmail 471 invoked from network); 25 Jan 1999 12:07:04 -0000 Message-Id: <36AC5E38.A7E9B0A3@kva.pvt.cz> Date: Mon, 25 Jan 1999 13:06:16 +0100 From: David Pospisilik X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: cs,en Mime-Version: 1.0 To: linux@linux.cz Subject: Re: tape, mt, amanda ... References: Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit Status: O Petr Snajdr wrote: > > Dobry den, > mam hafol otazek na spolupraci Linux - SCSI tape: > > 1) jaky je rozdil mezi /dev/st0 a /dev/nst0? No, dle myho znamyho je rozdil v pristupu: st0 je "rewindable" a nst0 "non-rewindable", takze pri ukonceni roztarovani se automaticky sama nepretoci (ma asi pravdu, zkousel jsem to :-)), da se tedy zjistit aktualni pozice pres 'mt', vkladat rucni separatory.... > 2) jak zatarovat na pasku 5 souboru a pak > roztarovat ten napr 3? Hraji si s kombinaci > tar a mt a snad to delam spatne nebo > snad nekde neco ne tak uplne funguje. > 3) jak zjistim kolik mista na tape je, kolik > archivu a datum ulozeni kazdeho > 4) pouzivate nekdo nejaky software > pro zalohovani z vice serveru jako je napr. Amanda? > Jake s ni/nim mate zkusenosti? > 5) Pouzivate nekdo nasledujici mechaniku a > jake s ni mate zkusenosti: > > Host: scsi0 Channel: 00 Id: 01 Lun: 00 > Vendor: ARCHIVE Model: Python 04106-XXX Rev: 7230 > Type: Sequential-Access ANSI SCSI revision: 02 > Ja jako pasku pouzivam DAT HP5000i, ale jelikoz mam trochu problemy s celkovou kombinaci PC/SCSI/DAT, tak s tim moc nelaboruji. Tim bych to i rad upresnil: Po ruzne dlouhe dobe mi zacina DATka delat podivne veci: zablika, odpoji se (zhasne, dotoci motory...) a za par vterin se zas nahodi, roztoci, rozblika.... Trva to vzdycky jen chvilku a vzdy jen v klidovem stavu, ale stava se mi, ze treba po patym "vypadku" uz nenabehne a delka vypadku se neustale prodluzuje. Skoro mi to pripomina, jako by ji neco pripravovalo o elektriku (zdroj ma rezervu). Pri provozu se taky obcas na vterinku pozastavi, ale to bude spis bufferem, nebo cistenim(?) hlavy. Radic mam Adaptec 2940, DATka ma id 6 a na tom samem radici jsou i systemove disky na nizsich id. Na Wirech mi to chodi uplne bez problemu. Je chyba v ovladaci Adaptecu?? (zkouseno i jako modul + initrd) K predchozim otazkam pripojim jeste svoji: 6) Jak pouzit soubor na pasce jako parametr prikazu?? Potreboval bych treba prehravat videa z pasky, ale napr XAnim neumi vstup ze stdin, tudiz nejde rourovat. Shanel jsem se po TapeFS, ale bez uspechu (stranka projektu jiz neexistuje) Dave > Predem dekuji za vsechny odpovedi > > S pozdravem > Petr Snajdr > > ---------------------------------------------------------------------- > Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list ---------------------------------------------------------------------- Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list From linux-return-33543-letty=mrakoplas.phil.muni.cz@linux.cz Mon Jan 25 13:28:07 1999 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id NAA27146 for ; Mon, 25 Jan 1999 13:28:01 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id NAA02438 for ; Mon, 25 Jan 1999 13:28:01 +0100 Received: from odysseus.linux.cz (vie2lDS2x3r6EzMMLBGAU/C1uQZ8Wk8T@[147.251.48.205]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with SMTP id NAA29849 for ; Mon, 25 Jan 1999 13:27:44 +0100 (MET) Received: (qmail 1674 invoked by uid 30); 25 Jan 1999 12:24:48 -0000 Mailing-List: contact linux-help@linux.cz; run by ezmlm Precedence: bulk Reply-To: linux@linux.cz Delivered-To: mailing list linux@linux.cz Received: (qmail 1666 invoked from network); 25 Jan 1999 12:24:46 -0000 Date: Mon, 25 Jan 1999 13:33:07 +0100 (MET) From: Robert Dobozy To: linux@linux.cz Subject: Re: tape, mt, amanda ... In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-MIME2LATIN2: 1 MIME parts converted to iso-8859-2 Status: O On Mon, 25 Jan 1999, Petr Snajdr wrote: > Dobry den, Dobry, > 1) jaky je rozdil mezi /dev/st0 a /dev/nst0? > 2) jak zatarovat na pasku 5 souboru a pak > roztarovat ten napr 3? Hraji si s kombinaci > tar a mt a snad to delam spatne nebo > snad nekde neco ne tak uplne funguje. No aj by som to urobil takto: tar cvf /dev/nst0 subor1 tar cvf /dev/nst0 subor2 tar cvf /dev/nst0 subor3 tar cvf /dev/nst0 subor4 tar cvf /dev/nst0 subor5 ^ | Ako uz bolo v inom maile povedane, tak N znamena "nonrewindable" zariadenie, takze tymto date na pasku za sebou 5 suborov. No a pristupit k tretiemu suboru mozete asi takto: mt -f /dev/nst0 fsf 2 t.j. posun sa o dve EOF znacky dopredu no a potom tar xv > 3) jak zjistim kolik mista na tape je, kolik > archivu a datum ulozeni kazdeho Kolik volneho ? Tak to nezistite. Ak ma mechanika HW kompresiu, tak uz vobec nie :-(. Jedine co sa da povedat je, ze mam DATku co ma 4GB nekomprimovanych a mam tam 2GB tak mam tam mimimalne 2GB miesta s kompresiou mozno aj 6GB. Kolik archivu. Jedine skusat mt fsf X, a ked to pri niektorom (dost velkom) X zareve tak viete kolko archivov tam mate ... Datum sa zistit neda a preto sa zvycajne dd-ckom alebo cpio-ckom na zaciatok pasky urobi pseudohlavicka, kde su ulozene potrebne informacie. Alebo sa archiv restorne na filesystem s prislusnymi prepinacmi (vid man) ktore hovoria o zachovani pristupovych prav a timestampu. Zostavam s pozdravom Robo ************************************************************************** * INTER-DATA s. r. o. * Phone: +421 7 443 73 710,443 73 714 * * Osadna 11 * Fax: +421 7 44373 053 * *831 03 Bratislava * E-mail: robo@idata.sk * * Slovak Republic * http://www.idata.sk * ************************************************************************** ---------------------------------------------------------------------- Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list From linux-return-33549-letty=mrakoplas.phil.muni.cz@linux.cz Mon Jan 25 14:20:53 1999 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id OAA29108 for ; Mon, 25 Jan 1999 14:20:53 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id OAA06261 for ; Mon, 25 Jan 1999 14:20:51 +0100 Received: from odysseus.linux.cz (19CrD2+F/dhml2vZ4DNoxFpivaMD8gNd@[147.251.48.205]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with SMTP id OAA06057 for ; Mon, 25 Jan 1999 14:20:34 +0100 (MET) Received: (qmail 7165 invoked by uid 30); 25 Jan 1999 13:00:06 -0000 Mailing-List: contact linux-help@linux.cz; run by ezmlm Precedence: bulk Reply-To: linux@linux.cz Delivered-To: mailing list linux@linux.cz Received: (qmail 7152 invoked from network); 25 Jan 1999 12:59:49 -0000 Message-ID: <00b801be4862$3909efe0$7d34c4c2@marek> From: "Marek Siwek" To: Subject: Re: tape, mt, amanda ... Date: Mon, 25 Jan 1999 13:55:49 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2106.4 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-2 X-MIME2LATIN2: 1 MIME parts converted to iso-8859-2 Status: O Ahoj, mam Exabyte nejak dal. no k tomu tarovani, chces ulozit 5 souboru najedonou, nebo postupne 5 po sobe jdoucich souboru? tar -xvf /dev/nst0 soubor3 /* prvni pripad mt -f /dev/nst0 fsf 3 tar -xvf /dev/nst0 /* druhy pripad mt -f /dev/nst0 tell /* ukaze momentalni pozici na pasku mt -f /dev/nst0 status /* nejake blizsi informace o pasku, vcetne cisla, na kterem cisle souboru se nachazis A pro Davida: existuje program wormdat pro pristup na pasku jako na normalni disk. Neni ani moc velky, jen je treba upravit na tvoji mechaniku. Jak? to prave skousim s tou moji. Nebo mohu poslat zdrojak na tvoji adresu ( asi 120kB) Mozna to trochu pomuze Marek Siwek marek.siwek@elektronika.cz ---------------------------------------------------------------------- Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list From linux-return-33540-letty=mrakoplas.phil.muni.cz@linux.cz Mon Jan 25 12:38:04 1999 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id MAA26527 for ; Mon, 25 Jan 1999 12:38:03 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id MAA31731 for ; Mon, 25 Jan 1999 12:38:03 +0100 Received: from odysseus.linux.cz (nR5Xzls4xbURlQOgoU9olB4KYlsHxfxS@[147.251.48.205]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with SMTP id MAA25024 for ; Mon, 25 Jan 1999 12:37:46 +0100 (MET) Received: (qmail 30571 invoked by uid 30); 25 Jan 1999 11:36:39 -0000 Mailing-List: contact linux-help@linux.cz; run by ezmlm Precedence: bulk Reply-To: linux@linux.cz Delivered-To: mailing list linux@linux.cz Received: (qmail 30562 invoked from network); 25 Jan 1999 11:36:38 -0000 X-Authentication-Warning: kompas.seznam.cz: snajdr owned process doing -bs Date: Mon, 25 Jan 1999 14:34:17 +0100 (MET) From: Petr Snajdr X-Sender: snajdr@kompas.seznam.cz To: linux@linux.cz Subject: tape, mt, amanda ... In-Reply-To: <199901251058.LAA24602@eniac.gvid.cz> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 8bit X-MIME2LATIN2: 1 MIME parts converted to iso-8859-2 Status: O Dobry den, mam hafol otazek na spolupraci Linux - SCSI tape: 1) jaky je rozdil mezi /dev/st0 a /dev/nst0? 2) jak zatarovat na pasku 5 souboru a pak roztarovat ten napr 3? Hraji si s kombinaci tar a mt a snad to delam spatne nebo snad nekde neco ne tak uplne funguje. 3) jak zjistim kolik mista na tape je, kolik archivu a datum ulozeni kazdeho 4) pouzivate nekdo nejaky software pro zalohovani z vice serveru jako je napr. Amanda? Jake s ni/nim mate zkusenosti? 5) Pouzivate nekdo nasledujici mechaniku a jake s ni mate zkusenosti: Host: scsi0 Channel: 00 Id: 01 Lun: 00 Vendor: ARCHIVE Model: Python 04106-XXX Rev: 7230 Type: Sequential-Access ANSI SCSI revision: 02 Predem dekuji za vsechny odpovedi S pozdravem Petr Snajdr ---------------------------------------------------------------------- Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list From linux-return-33610-letty=mrakoplas.phil.muni.cz@linux.cz Mon Jan 25 22:15:03 1999 Return-Path: Received: from lvt.phil.muni.cz (root@lvt.phil.muni.cz [147.251.96.1]) by mrakoplas.phil.muni.cz (8.8.7/8.8.5) with ESMTP id WAA01466 for ; Mon, 25 Jan 1999 22:15:03 +0100 Received: from aragorn.ics.muni.cz (aragorn.ics.muni.cz [147.251.4.33]) by lvt.phil.muni.cz (8.9.1/8.8.5) with ESMTP id WAA21806 for ; Mon, 25 Jan 1999 22:15:02 +0100 Received: from odysseus.linux.cz ([147.251.48.205]) by aragorn.ics.muni.cz (8.8.5/8.8.5) with SMTP id WAA08429 for ; Mon, 25 Jan 1999 22:14:46 +0100 (MET) Received: (qmail 24921 invoked by uid 30); 25 Jan 1999 21:12:40 -0000 Mailing-List: contact linux-help@linux.cz; run by ezmlm Precedence: bulk Reply-To: linux@linux.cz Delivered-To: mailing list linux@linux.cz Received: (qmail 24891 invoked from network); 25 Jan 1999 21:12:30 -0000 To: linux@linux.cz Date: 25 Jan 1999 21:50:30 +0100 From: Stanislav Meduna Message-ID: <78ilem$7od$1@trillian.eunet.sk> Organization: Trillian point, Bratislava, Slovakia Sender: cz-comp-linux@pandion.vslib.cz References: <199901251058.LAA24602@eniac.gvid.cz>, Subject: Re: tape, mt, amanda ... Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-2 X-MIME2LATIN2: 1 MIME parts converted to iso-8859-2 Status: O On 25 Jan 1999 12:37:58 +0100, Petr Snajdr wrote: : 2) jak zatarovat na pasku 5 souboru a pak : roztarovat ten napr 3? Hraji si s kombinaci : tar a mt a snad to delam spatne nebo : snad nekde neco ne tak uplne funguje. Kedysi som sa s niecim podobnym trapil a ked uz som mal vytrhane skoro vsetky vlasy, poradila mi nejaka dobra dusa z Internetu, ze nie je mt ako mt. Zakopany pes bol myslim v mt setblk 0. V SCSI-HOWTO sa pise: > You can do this with the mt command - > > mt setblk > > or > > mt setblk 0 > > to get variable block length support. > > Note that these mt flags are NOT supported under the GNU version of mt > which is included with some Linux distributions. Instead, you must > use the BSD derived Linux SCSI mt command. Source should be available > from > > tsx-11.mit.edu:/pub/linux/ALPHA/scsi : Host: scsi0 Channel: 00 Id: 01 Lun: 00 : Vendor: ARCHIVE Model: Python 04106-XXX Rev: 7230 : Type: Sequential-Access ANSI SCSI revision: 02 ... a pravdu povediac, nejaky Archive Python to bol. Pozriem este v robote do mailboxu, mozno som si tu diskusiu schoval. Zdravi -- Stano ---------------------------------------------------------------------- Meta-FAQ (odhlá¹ení, archív a dal¹í): http://www.linux.cz/mailing-list