From owner-freebsd-scsi Sun Dec 7 19:09:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA20794 for freebsd-scsi-outgoing; Sun, 7 Dec 1997 19:09:13 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA20784 for ; Sun, 7 Dec 1997 19:09:08 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id EAA01959 for freebsd-scsi@FreeBSD.ORG; Mon, 8 Dec 1997 04:09:05 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id CAA12718; Mon, 8 Dec 1997 02:04:31 +0100 (CET) (envelope-from roberto) Message-ID: <19971208020431.58490@keltia.freenix.fr> Date: Mon, 8 Dec 1997 02:04:31 +0100 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: AHC optimizations References: <199712060144.XAA25942@gaia.coppe.ufrj.br> <199712060630.XAA03061@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712060630.XAA03061@pluto.plutotech.com>; from Justin T. Gibbs on Fri, Dec 05, 1997 at 11:29:03PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3861 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Justin T. Gibbs: > with CAM, and if you are running that code, I have many more tools to Speaking of CAM, is there a version of your files/patches that doesn't require to download between 5 and 14 MB of files ? The most recent files cam-* on wcarchive's incoming are about that size. That's a bit too much for me to download across the Atlantic :-( BTW still no ncr support I suppose ? -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Tue Nov 25 22:32:12 CET 1997 From owner-freebsd-scsi Sun Dec 7 22:15:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA03359 for freebsd-scsi-outgoing; Sun, 7 Dec 1997 22:15:39 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA03348 for ; Sun, 7 Dec 1997 22:15:35 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.7/8.7.3) id XAA07709; Sun, 7 Dec 1997 23:13:46 -0700 (MST) Date: Sun, 7 Dec 1997 23:13:46 -0700 (MST) Message-Id: <199712080613.XAA07709@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712060144.XAA25942@gaia.coppe.ufrj.br> <199712060630.XAA03061@pluto.plutotech.com> <19971208020431.58490@keltia.freenix.fr> In-Reply-To: <19971208020431.58490@keltia.freenix.fr> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: AHC optimizations X-Original-Newsgroups: pluto.freebsd.scsi To: Ollivier Robert cc: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <19971208020431.58490@keltia.freenix.fr>, Ollivier Robert writes: > According to Justin T. Gibbs: >> with CAM, and if you are running that code, I have many more tools to > > Speaking of CAM, is there a version of your files/patches that doesn't > require to download between 5 and 14 MB of files ? The most recent files > cam-* on wcarchive's incoming are about that size. > > That's a bit too much for me to download across the Atlantic :-( The "official" snapshots are composed of diffs and a tarfile of the new files. There has only been one official snapshot so far with the rest being quick tarballs for specific testers. The next official snapshot was supposed to go out tonight, but I'm still dealing with some tape driver bugs. I hope to get it out tomorrow. > BTW still no ncr support I suppose ? Are you volunteering? -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Dec 7 23:51:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12921 for freebsd-scsi-outgoing; Sun, 7 Dec 1997 23:51:48 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12903 for ; Sun, 7 Dec 1997 23:51:40 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA07275; Mon, 8 Dec 1997 08:51:32 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id IAA27799; Mon, 8 Dec 1997 08:36:29 +0100 (MET) Message-ID: <19971208083629.21248@uriah.heep.sax.de> Date: Mon, 8 Dec 1997 08:36:29 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: Paul Saab Subject: Re: error message Reply-To: Joerg Wunsch References: <199712040520.XAA06820@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712040520.XAA06820@elvis.mu.org>; from Paul Saab on Wed, Dec 03, 1997 at 11:20:26PM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Paul Saab wrote: > I got this message today from a machine which we have never had a > problem with and I am befuddled and was hoping someone could tell > me what the following means. > Dec 3 22:12:34 tranq1 /kernel: aha0: MBO 01 and not 00 (free) That's usually the result of some gross SCSI bus problem. Either your SCSI bus is malfunctioning (like a terminator vanished), or some target is going south and does no longer respond. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Sun Dec 7 23:52:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA12994 for freebsd-scsi-outgoing; Sun, 7 Dec 1997 23:52:05 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA12953 for ; Sun, 7 Dec 1997 23:51:59 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id IAA07291; Mon, 8 Dec 1997 08:51:56 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id IAA27826; Mon, 8 Dec 1997 08:46:43 +0100 (MET) Message-ID: <19971208084642.60694@uriah.heep.sax.de> Date: Mon, 8 Dec 1997 08:46:42 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: "Bryan K. Ogawa" Subject: Re: Adaptec 1502AE and SCSI Scanner? Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from Bryan K. Ogawa on Thu, Dec 04, 1997 at 03:41:42AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Bryan K. Ogawa wrote: > Under FreeBSD, though, I'm having some problems running it on the SCSI > card it comes with (Adaptec 1502AE). Oh well, the aic driver is totally unmaintained these days. You're most welcome as a maintainer, of course. :) > I think I have correctly captured the previous scsi command as > > 4 0 9 0 8 0 Sounds rather unlikely to me. Opcode 4 would be "Format unit". Anyway, i don't know much about scanners either. > On a side note, if it does turn out that this won't work, does anyone have > any information on the Adaptec 2902 or cheap NCR 8xx cards with an > external connector? The NCR 810 controllers are indeed cheap yet as powerful as e.g. an AHA2940 (minus the missing on-board BIOS and EEPROM for configuration data). I've recently bought one for DEM 80 (~ USD 50). However, you should make sure first that your scanner properly disconnects from the bus. Some cheap scanners don't, and that's one of the reasons why the vendors ship them along with a separate adapter (which is meant to be used solely with that scanner then). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Mon Dec 8 02:51:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA27282 for freebsd-scsi-outgoing; Mon, 8 Dec 1997 02:51:25 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA27265 for ; Mon, 8 Dec 1997 02:51:16 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (d60-090.leach.ucdavis.edu [169.237.60.90]) by relay.nuxi.com (8.8.7/8.6.12) with ESMTP id CAA28754; Mon, 8 Dec 1997 02:51:15 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.7/8.7.3) id KAA25509; Mon, 8 Dec 1997 10:51:07 GMT Message-ID: <19971208025107.23119@dragon.nuxi.com> Date: Mon, 8 Dec 1997 02:51:07 -0800 From: "David O'Brien" To: Tom Cc: freebsd-scsi@freebsd.org Subject: Re: ahc deferred error Reply-To: obrien@NUXI.com References: <0oVlG3W00YUo0eZ0g0@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Tom on Fri, Dec 05, 1997 at 10:05:59AM -0800 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > You might want to check to see that auto read/write relocation is turned > on for the drive. How would you do that? -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) James says: "Grad school sucks." From owner-freebsd-scsi Mon Dec 8 10:49:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA28393 for freebsd-scsi-outgoing; Mon, 8 Dec 1997 10:49:05 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA28386 for ; Mon, 8 Dec 1997 10:48:58 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id TAA26647 for freebsd-scsi@FreeBSD.ORG; Mon, 8 Dec 1997 19:48:23 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id TAA16108; Mon, 8 Dec 1997 19:14:19 +0100 (CET) (envelope-from roberto) Message-ID: <19971208191418.30448@keltia.freenix.fr> Date: Mon, 8 Dec 1997 19:14:18 +0100 From: Ollivier Robert To: freebsd-scsi@FreeBSD.ORG Subject: Re: ahc deferred error References: <0oVlG3W00YUo0eZ0g0@andrew.cmu.edu> <19971208025107.23119@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19971208025107.23119@dragon.nuxi.com>; from David O'Brien on Mon, Dec 08, 1997 at 02:51:07AM -0800 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3861 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to David O'Brien: > How would you do that? 354 [19:13] root@keltia:~# scsi -f /dev/rsd0.ctl -m 1 AWRE (Auto Write Reallocation Enbld): 1 ARRE (Auto Read Reallocation Enbld): 1 TB (Transfer Block): 0 RC (Read Continuous): 0 EER (Enable Early Recovery): 0 PER (Post Error): 0 DTE (Disable Transfer on Error): 0 DCR (Disable Correction): 0 Read Retry Count: 1 Correction Span: 0 Head Offset Count: 0 Data Strobe Offset Count: 0 Write Retry Count: 1 Recovery Time Limit: 0 The first two lines are the ones you want. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Tue Nov 25 22:32:12 CET 1997 From owner-freebsd-scsi Mon Dec 8 13:02:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA10768 for freebsd-scsi-outgoing; Mon, 8 Dec 1997 13:02:49 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from nomis.simon-shapiro.org (nomis.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA10742 for ; Mon, 8 Dec 1997 13:02:30 -0800 (PST) (envelope-from shimon@nomis.Simon-Shapiro.ORG) Received: (qmail 9989 invoked by uid 1000); 8 Dec 1997 21:03:05 -0000 Message-ID: X-Mailer: XFMail 1.2-beta-120197 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3.0.32.19971205144421.009495d0@gw1.tesys.com> Date: Mon, 08 Dec 1997 13:03:05 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Harry Aulakh Subject: RE: configuring RAID in FreeBSD 2.2.5 Cc: raj@gw1.tesys.com, freebsd-scsi@FreeBSD.ORG, Yun-Ching Lee , Tom , John Dowdal Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 05-Dec-97 Harry Aulakh wrote: > Hello Friends > I want to configure RAID-1 in FreeBSD2.2.5 either in software > based > or hardware based.I donot know freebsd 2.2.5 are support software > RAID or not. > My question are > a) Is there any support in freebsd 2.2.5 to configure software RAID > (any > level)? > If YES then how can I do It. > b) Is the FreeBSD2.2.5 are supporting any RAID controller card (like > DPT).? Yes. Goto http://simon-shapiro.org > > Harry Aulakh > Sr. Engineer > Telenet System Solution Inc. > 2480 kruse drive > San Jose Ca-95131 > Phone 408-383-0334 ext 111 > fax 408-383-0335 > Web www.tesys.com ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 Windows NT: n. 32-bit extensions and a graphical shell for a 16-bit patch to an 8-bit operating system originally coded for a 4-bit microprocessor, written by a 2-bit company that can't stand for 1 bit of competition. From owner-freebsd-scsi Mon Dec 8 13:32:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA14709 for freebsd-scsi-outgoing; Mon, 8 Dec 1997 13:32:25 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from frmug.org (frmug-gw.frmug.org [193.56.58.252]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA14679 for ; Mon, 8 Dec 1997 13:32:12 -0800 (PST) (envelope-from roberto@keltia.freenix.fr) Received: (from uucp@localhost) by frmug.org (8.8.8/frmug-2.1/nospam) with UUCP id WAA17531 for scsi@FreeBSD.org; Mon, 8 Dec 1997 22:31:57 +0100 (CET) (envelope-from roberto@keltia.freenix.fr) Received: (from roberto@localhost) by keltia.freenix.fr (8.8.8/keltia-2.13/nospam) id VAA26844; Mon, 8 Dec 1997 21:51:14 +0100 (CET) (envelope-from roberto) Message-ID: <19971208215113.12258@keltia.freenix.fr> Date: Mon, 8 Dec 1997 21:51:13 +0100 From: Ollivier Robert To: scsi@FreeBSD.org Subject: Re: AHC optimizations References: <199712060144.XAA25942@gaia.coppe.ufrj.br> <199712060630.XAA03061@pluto.plutotech.com> <19971208020431.58490@keltia.freenix.fr> <199712080613.XAA07709@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712080613.XAA07709@narnia.plutotech.com>; from Justin T. Gibbs on Sun, Dec 07, 1997 at 11:13:46PM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3880 AMD-K6 MMX @ 208 MHz Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk According to Justin T. Gibbs: > snapshot was supposed to go out tonight, but I'm still dealing with > some tape driver bugs. I hope to get it out tomorrow. OK, thanks. > > BTW still no ncr support I suppose ? > Are you volunteering? I'm afraid not :-( My knowledge has just entered the VFS area and drivers are still too far ahead. It is just that I can't test CAM till there is ncr support in it :-) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Tue Nov 25 22:32:12 CET 1997 From owner-freebsd-scsi Mon Dec 8 20:15:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA24363 for freebsd-scsi-outgoing; Mon, 8 Dec 1997 20:15:18 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA24340; Mon, 8 Dec 1997 20:15:10 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id VAA29018; Mon, 8 Dec 1997 21:15:09 -0700 (MST) Message-Id: <199712090415.VAA29018@pluto.plutotech.com> Date: Mon, 08 Dec 1997 21:13:29 -0700 From: "Justin T. Gibbs" Subject: 971208 CAM Snapshot Available Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk To: undisclosed-recipients:; ------- Blind-Carbon-Copy Subject: 971208 CAM Snapshot Available Date: Mon, 08 Dec 1997 21:13:29 -0700 From: "Justin T. Gibbs" Bcc: Blind Distribution List: ; Common Access Method SCSI layer Patches Available You've all seen messages talking about a new SCSI layer for FreeBSD, and I'm pleased to announce yet another snapshot of that work. I plan to release snapshots on a regular basis as new features and hardware support are added. To see what is currently supported, skip down to the supported hardware section. "What is CAM? and why would I want it?" CAM is an ANSI ratified spec that defines a software interface for talking to SCSI and ATAPI devices. This new SCSI layer for FreeBSD is not strictly CAM compliant, but follows many of the precepts of CAM. More importantly, this work addresses many of the short comings of the previous SCSI layer and should provide better performance, reliability, and ease the task of adding support for new controllers. I hope that many of you will try CAM. Although "work in progress", this code has been through over four months of testing here at Pluto and I feel pretty good about the stability of the code. If you do have the facilities to experiment (you must be running current), please do. I welcome your feedback especially about the performance of the new system. Features Since Last Snapshot: Preliminary tape support. This has only been tested on a DDS2 drive and the driver is fairly green. New device statistic code. A whole slew of information is now recorded on a per-device basis. The interface is generic and once we have iostat and systat converted to using this code, all other drivers using the old "dk" stat interface will be converted. A sample utility is included in this snapshot so you can read the statistics. Bus DMA based bounce buffer support. ISA AdvanSys support now works in all memory configurations. aic7xxx driver improvements. The aic7895 is now supported. The command queing algorithm is now more efficient. Bug fixes include some problems with error recovery and target initiated sync/wide negotiation. AdvanSys driver improvements. The driver has now been tested on almost every narrow SCSI card AdvanSys has produced. Many bugs in the device probe code have been fixed. Table driven error handling. This greatly simplifies the task of enhancing or modifying how errors are handled. Enhanced PCI conf support. Although this isn't really CAM related, you get it for free. Check out the pciconf utilty for details. Numerous other bug fixes I've forgotten about. Features: Round-robin, per priority level scheduling of devices and their resources. I/O Completion, error recovery, and processing queued I/O is performed in a separate software interrupt handler. The old system had the potential of blocking out hardware interrupts for lengthy periods as much of this processing occurred as the result of a call from the controller's interrupt handler. The generic SCSI layer now understands tagged I/O and exports this functionality to the peripheral drivers. This allows drivers like the "direct access" driver to perform ordered tagged transactions for meta-data writes. Async, ordered, meta-data writes are now enabled in vfs_bio.c The "direct access" driver prevents "tag starvation" from occurring by guaranteeing that at least one write in every 5 second period to a tagged queuing device has an ordered tag. This removes the need for individual controller drivers to worry about this problem. Complete and controller independent handling of the "QUEUE FULL" and "BUSY" status codes. The number of tags that are queued to a device are dynamically adjusted by the generic layer. Interrupt driven sub-device probing. At boot time, all buses are probed in parallel yielding a much faster boot. As probing occurs after all interrupt and timer services are available, no additional (and often error prone) "polling" code is needed in each controller driver. Better error recovery. When an error occurs, the queue of transactions to the erring device is "frozen", full status is reported back to the peripheral driver, and the peripheral driver can recover the device without perturbing queued up I/O. As all transactions have an associated priority and generation count, after recovery is complete, transactions that are retried are automatically re-queued in their original order. All error handling is performed based on a detected failure. The old code would often perform actions "just in case" before accessing a device as the error recovery mechanism was inadequate. Now, for example, if your disk spins down, the system will properly recover even if the device is already open. Support for "high power" commands. Peripheral drivers can mark actions that may tax a power supply as "high powered". Only a certain number (default of 4, but configurable with the CAM_MAX_HIGHPOWER kernel option) of these commands are allowed to be active at a time. This allows a user to, for example, disable spin-up on the drives in an enclosure and let the system spin them up in a controlled fashion. By default, all luns are scanned on devices during probe. In the old SCSI layer, this was often problematic as it performed a Test Unit Ready prior to performing an Identify. Many devices that properly handle the Identify will hang the bus if you attempt a different command to a high lun. Transfer negotiations only occurs to devices that actually support negotiations (based on their inquiry information). This is performed in a controller independent fashion. There is now a generic quirk mechanism that allows controllers, peripheral drivers, or the CAM transport layer to define their own quirks entries. Currently the CAM transport layer has quirk entries that allow for modulation of tags and disabling multi-lun probing. The AdvanSys driver uses quirk entries to control some of the "hardware bug fixes" in the driver that only apply to certain types of devices. Hard-wiring of devices to specific unit numbers is supported as it was in the old system. Userland "pass-through" commands are supported. The interface is different than from the old SCSI code, but sample code is provided (including patches to XMCD), and we do plan to provide a scsi.8 command in the future. SUPPORTED HARDWARE Aic7xxx driver (ahc): This driver supports all of the devices the original FreeBSD driver supports but with the following new features: Support for aic7895 based controllers. Autotermination support for aic7860 based cards. SCB paging that allows up to 255 SCBs to be active on aic7770, aic7850, and aic7860 cards. Bug fixes to the multi-lun support. The beginnings of a target mode implementation. AdvanSys Driver (adv): This driver supports the entire line of AdvanSys narrow channel devices. Tagged queuing is also supported. Supported peripherals: Direct Access driver (da): 512 byte sectored disk drivers. Support for other sector sizes is planned, but further investigation on the "right" approach for this is needed. It probably belongs in the disk-slice code. CDROM driver (cd): This driver should support everything the old driver did. Sequential Access driver (sa): This driver should support most "newer" tape drives. It does not have the ability to change either the density or compression settings yet. This is the "greenest" component in CAM currently, having only been tested on an Archive Python. Look for additional enhancements to this driver in the near term. Other peripheral drivers are in the works. HOW TO INSTALL IT BACKUP YOUR OLD SRC TREE AND KERNEL!!!! cp /kernel /kernel.works Get the code: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971208.diffs.gz ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971208.samples.tar.gz or ftp://ftp.kdm.org/pub/FreeBSD/cam/cam-971208.diffs.gz ftp://ftp.kdm.org/pub/FreeBSD/cam/cam-971208.samples.tar.gz On a FreeBSD-current system from ~971208: cd /usr/src zcat cam-971208.diffs.gz | patch cd usr.sbin/config make clean all install cd sys/i386/conf vi MYKERNEL Comment out all unsupported SCSI devices, and substitute "da" for "sd" and "sa" for "st". Look in LINT or GENERIC for examples. config MYKERNEL cd ../../MYKERNEL make all make install If you want XMCD or the userland sample code, untar cam-971208.samples.tar.gz and read the enclosed README files. - -- Justin T. Gibbs gibbs@FreeBSD.org =========================================== FreeBSD - Turning PCs into workstations =========================================== ------- End of Blind-Carbon-Copy From owner-freebsd-scsi Tue Dec 9 02:43:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA22326 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 02:43:44 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA22321; Tue, 9 Dec 1997 02:43:41 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: from dragon.nuxi.com (d60-090.leach.ucdavis.edu [169.237.60.90]) by relay.nuxi.com (8.8.7/8.6.12) with ESMTP id CAA09524; Tue, 9 Dec 1997 02:43:40 -0800 (PST) Received: (from obrien@localhost) by dragon.nuxi.com (8.8.7/8.7.3) id KAA07028; Tue, 9 Dec 1997 10:43:25 GMT Message-ID: <19971209024325.53867@dragon.nuxi.com> Date: Tue, 9 Dec 1997 02:43:25 -0800 From: "David O'Brien" To: Scott Watters Cc: freebsd-questions@freebsd.org, freebsd-scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem Reply-To: obrien@NUXI.com References: <01bd01bc$98a6a760$4560f2cf@curious.vina-tech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <01bd01bc$98a6a760$4560f2cf@curious.vina-tech.com>; from Scott Watters on Fri, Dec 05, 1997 at 12:30:16PM -0800 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > the tape. It expects, correctly I think, to receive an EOM (end > of media) error when the tape gets to the end of recorded data. > However mt never returns an error, but the kernel logs a message > like this: > > Dec 3 17:42:14 newserver /kernel: st0(ahc0:6:0): BLANK CHECK req sz: 1 > (decimal) asc:0,5 End-of-data detected Probably the same bug that keeps ``dump 0a'' from working. -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) From owner-freebsd-scsi Tue Dec 9 12:52:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04419 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 12:52:08 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA04314 for ; Tue, 9 Dec 1997 12:51:54 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id VAA28990; Tue, 9 Dec 1997 21:51:36 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id VAA04161; Tue, 9 Dec 1997 21:21:11 +0100 (MET) Message-ID: <19971209212111.18810@uriah.heep.sax.de> Date: Tue, 9 Dec 1997 21:21:11 +0100 From: J Wunsch To: Yun-Ching Lee Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: ahc deferred error Reply-To: Joerg Wunsch References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: ; from John Dowdal on Fri, Dec 05, 1997 at 03:25:38PM -0500 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As John Dowdal wrote: > Bad144 might be able to work for a week or two, but its not a very good > solution. > > If you at all care about what is on the disk, this is the point where you > should either claim its warranty if it has one, or else buy a new disk. I've made good experience for some older Seacrate by simply reformatting it at this point. Of course, i didn't use it for important data afterwards, but it's still all alive. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Tue Dec 9 13:23:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA06696 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 13:23:09 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA06689 for ; Tue, 9 Dec 1997 13:23:04 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id WAA29265; Tue, 9 Dec 1997 22:22:50 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id WAA04277; Tue, 9 Dec 1997 22:01:21 +0100 (MET) Message-ID: <19971209220121.10232@uriah.heep.sax.de> Date: Tue, 9 Dec 1997 22:01:21 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: Scott Watters Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <01bd01bc$98a6a760$4560f2cf@curious.vina-tech.com> <19971209024325.53867@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <19971209024325.53867@dragon.nuxi.com>; from David O'Brien on Tue, Dec 09, 1997 at 02:43:25AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As David O'Brien wrote: > > Dec 3 17:42:14 newserver /kernel: st0(ahc0:6:0): BLANK CHECK req sz: 1 > > (decimal) asc:0,5 End-of-data detected > > Probably the same bug that keeps ``dump 0a'' from working. At least a related one, but not the same. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Tue Dec 9 13:29:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA07470 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 13:29:37 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from vina-tech.com (vina-tech.com [207.242.96.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA07462 for ; Tue, 9 Dec 1997 13:29:35 -0800 (PST) (envelope-from scott.watters@vina-tech.com) Received: from curious (curious.vina-tech.com [207.242.96.69]) by vina-tech.com (8.8.7/8.8.7) with SMTP id NAA25885 for ; Tue, 9 Dec 1997 13:28:11 -0800 (PST) (envelope-from scott.watters@vina-tech.com) Message-ID: <007601bd04e9$48a33af0$4560f2cf@curious.vina-tech.com> Reply-To: "Scott Watters" From: "Scott Watters" To: Subject: Re: Questions about mt and SCSI subsystem Date: Tue, 9 Dec 1997 13:27:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >As David O'Brien wrote: > >> > Dec 3 17:42:14 newserver /kernel: st0(ahc0:6:0): BLANK CHECK req sz: 1 >> > (decimal) asc:0,5 End-of-data detected >> >> Probably the same bug that keeps ``dump 0a'' from working. > >At least a related one, but not the same. >-- >cheers, J"org > >joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE >Never trust an operating system you don't have sources for. ;-) I did a ktrace on mt and discovered that the driver was NOT returning an error on the fsf IOCTL. It looks like a driver problem. I've been looking at the sources, but the EOM logic escapes me. Has anyone else played with/patched this code? I know the logic is complex due to asychronous IO and early returns. But I can't see the forest for the trees. Thanks, Scott Watters scott.watters@vina-tech.com http://www.vina-tech.com From owner-freebsd-scsi Tue Dec 9 16:49:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA24466 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 16:49:59 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from fly.HiWAAY.net (root@fly.HiWAAY.net [208.147.154.56]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA24460 for ; Tue, 9 Dec 1997 16:49:46 -0800 (PST) (envelope-from dkelly@nospam.hiwaay.net) Received: from nospam.hiwaay.net (tnt1-40.HiWAAY.net [208.147.147.40]) by fly.HiWAAY.net (8.8.7/8.8.6) with ESMTP id SAA15598 for ; Tue, 9 Dec 1997 18:49:38 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by nospam.hiwaay.net (8.8.8/8.8.4) with ESMTP id SAA25972 for ; Tue, 9 Dec 1997 18:37:39 -0600 (CST) Message-Id: <199712100037.SAA25972@nospam.hiwaay.net> X-Mailer: exmh version 2.0zeta 7/24/97 To: freebsd-scsi@freebsd.org From: David Kelly Subject: Re: Questions about mt and SCSI subsystem In-reply-to: Message from "Scott Watters" of "Tue, 09 Dec 1997 13:27:42 PST." <007601bd04e9$48a33af0$4560f2cf@curious.vina-tech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 09 Dec 1997 18:37:39 -0600 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Scott Watters wrote: > > I did a ktrace on mt and discovered that the driver was NOT > returning an error on the fsf IOCTL. It looks like a driver > problem. I've been looking at the sources, but the EOM logic > escapes me. Has anyone else played with/patched this code? > I know the logic is complex due to asychronous IO and early > returns. But I can't see the forest for the trees. I got lost in there too. Not sure if we ever write an EOT marker but did see somewhere in the code where we write a couple of extra EOF's to mark where we thing the end is when we close the tape. There was also some test for moving back toward the start of the tape that would trigger write of EOF's. Is this the kind of thing the CAM code is addressing? I too am very interested in improving tape handling. Went so far as to order (and get) Seagate's DAT SCSI manual (it was free, I like Seagate) and told the boss to order the Exabyte manual ($55) but Nobody Has Bothered Yet. To get my feet wet, started by porting tcopy from FreeBSD to Irix. Found big differences in tape handling between Irix 6.2 and 6.3. Other fires popped up so I haven't been back to that in weeks but the boss agreed it was promising enough that I've snagged an SGI R5000 O2 and a couple 8mm Exabyte 8505's. Darn it, those Exabytes sure look nice and work well on my FreeBSD system. Along with two 4mm's. Needless to say, at work we like tape. If I can get a couple of things worked out with FreeBSD, tcopy, Exabyte, Seagate 4mm's, and Qualtech (? Kennedy) 9-track tape drives, then I'll have homes for about 10 FreeBSD systems as tape copy stations. Currently we use Sun's because they come with tcopy and SGI doesn't. Before I came along nobody ever heard of FreeBSD. They are getting earfuls now. We've had several instances where Sun's tcopy didn't accurately detect the end of tape and stopped early. Some old systems, probably VAX's, often wrote multiple EOF's between tape files, but happily skipped over those. Sun has a "Berkeley" tape device, aka /dev/rmt/0b, which is supposed to deal with this. We've had egg on our face once too many times when a tape was shipped without all its data so now we have a manual procedure for detecting this situation and problem tapes are marked accordingly. Rough guess right now is that EOT on 8mm's is going to be a problem. Suspect the low density 8mm format doesn't have an EOT marker. Need the book to know if its supposed to, but empirical evidence suggests its not there. I also worry about translating an original tape's (3) EOF's between files into a single EOF, but so far this modernization hasn't prompted any complaints. The other thing is the customer has developed a "statistics" fetish. This isn't so bad as knowing the length of tape, bytes copied, etc, is exactly the thing needed to detect premature end of tape. I can query SGI's tape device for current position and know what block I'm on. That's good enough. Its not hard for tcopy to count the bytes it writes either. Meanwhile The Boss buys TTi packaged 8mm drives for twice the street price because they have displays which show how much tape has been used. So far I want to enhance tcopy (and/or st(4)) to provide these statistics and accurately detect end of tape. But further would like to be able to write multiple copies of a tape in parallel. And would also like to develop a disk file format whereby a tape (of unknown format) could be stored and later reproduced. Let me add, I like SGI's "mt" command. "mt status" is full of all kinds of useful info (such as tape position, drive manufacturer's model #)and its output is shorter than FreeBSD's. I like the way SGI blocks on tape access when the drive is temporarily busy loading tape. I don't like the nasty message FreeBSD and Solaris deliver. -- David Kelly N4HHE, dkelly@nospam.hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. From owner-freebsd-scsi Tue Dec 9 17:05:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25607 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 17:05:17 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA25599 for ; Tue, 9 Dec 1997 17:05:11 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA02362; Wed, 10 Dec 1997 01:51:35 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA05129; Wed, 10 Dec 1997 01:34:27 +0100 (MET) Message-ID: <19971210013427.36373@uriah.heep.sax.de> Date: Wed, 10 Dec 1997 01:34:27 +0100 From: J Wunsch To: freebsd-scsi@FreeBSD.ORG Cc: Scott Watters Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <007601bd04e9$48a33af0$4560f2cf@curious.vina-tech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <007601bd04e9$48a33af0$4560f2cf@curious.vina-tech.com>; from Scott Watters on Tue, Dec 09, 1997 at 01:27:42PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Scott Watters wrote: > I did a ktrace on mt and discovered that the driver was NOT > returning an error on the fsf IOCTL. It looks like a driver It really wouldn't have required a ktrace run to tell you this. :-) > problem. I've been looking at the sources, but the EOM logic > escapes me. Has anyone else played with/patched this code? I once tried to fix the EOF bug, but eventually gave up for lack of time understanding all this code, pending flags, etc. (and filed a PR for it). > I know the logic is complex due to asychronous IO and early > returns. But I can't see the forest for the trees. You are not alone. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Tue Dec 9 18:45:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04034 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 18:45:28 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04029 for ; Tue, 9 Dec 1997 18:45:22 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.7/8.7.3) id TAA18226; Tue, 9 Dec 1997 19:43:28 -0700 (MST) Date: Tue, 9 Dec 1997 19:43:28 -0700 (MST) Message-Id: <199712100243.TAA18226@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712100037.SAA25972@nospam.hiwaay.net> In-Reply-To: <199712100037.SAA25972@nospam.hiwaay.net> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: Questions about mt and SCSI subsystem X-Original-Newsgroups: pluto.freebsd.scsi To: David Kelly cc: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <199712100037.SAA25972@nospam.hiwaay.net>, David Kelly writes: > Scott Watters wrote: >> >> I did a ktrace on mt and discovered that the driver was NOT >> returning an error on the fsf IOCTL. It looks like a driver >> problem. I've been looking at the sources, but the EOM logic >> escapes me. Has anyone else played with/patched this code? >> I know the logic is complex due to asychronous IO and early >> returns. But I can't see the forest for the trees. > > I got lost in there too. Not sure if we ever write an EOT marker but > did see somewhere in the code where we write a couple of extra EOF's to > mark where we thing the end is when we close the tape. There was also > some test for moving back toward the start of the tape that would > trigger write of EOF's. In SCSI, there is no such thing as an "EOT" marker. Instead, you must follow the convention for whatever type of tape media you are writing too for designating "EOT". This can be "nothing", a pattern of filemarks, or an erase gap. The current st driver only does the "double filemark" thing. I still need to do more research on which formats require what kind of EOT handling. > Is this the kind of thing the CAM code is addressing? The CAM code has a new tape driver and I certainly hope that it will address the problems the current st driver has. Unfortunately, I only have access to Exabyte and DDS2 drives at the moment, and it's hard to find all the details on historical tape writing conventions. > We've had several instances where Sun's tcopy didn't accurately detect > the end of tape and stopped early. Some old systems, probably VAX's, > often wrote multiple EOF's between tape files, but happily skipped over > those. Sun has a "Berkeley" tape device, aka /dev/rmt/0b, which is > supposed to deal with this. We've had egg on our face once too many > times when a tape was shipped without all its data so now we have a > manual procedure for detecting this situation and problem tapes are > marked accordingly. The Berkeley convention was that 2 filemarks in a row signaled EOT. Unfortunately, this doesn't work out so well if someone decides to write a 0 length file. The FreeBSD st driver (including the CAM one), return EIO when a filemark is encountered or a "blank check" is reported. It's up to the reading program to decide what that means. > Rough guess right now is that EOT on 8mm's is going to be a problem. > Suspect the low density 8mm format doesn't have an EOT marker. Need the > book to know if its supposed to, but empirical evidence suggests its > not there. You're supposed to get a "blank check" from the drive once you traverse beyond EOD (End of Data). > I also worry about translating an original tape's (3) EOF's between > files into a single EOF, but so far this modernization hasn't prompted > any complaints. Isn't this for the application to decide? > The other thing is the customer has developed a "statistics" fetish. > This isn't so bad as knowing the length of tape, bytes copied, etc, is > exactly the thing needed to detect premature end of tape. I can query > SGI's tape device for current position and know what block I'm on. > That's good enough. Its not hard for tcopy to count the bytes it writes > either. Meanwhile The Boss buys TTi packaged 8mm drives for twice the > street price because they have displays which show how much tape has > been used. Assuming the device supports the READ POSITION scsi command, there's no reason we can't add this feature to mt/sa(4). I believe that mjacob has already added this to NetBSD. > So far I want to enhance tcopy (and/or st(4)) to provide these > statistics and accurately detect end of tape. But further would like to > be able to write multiple copies of a tape in parallel. And would also > like to develop a disk file format whereby a tape (of unknown format) > could be stored and later reproduced. Right now, we only have a single error code to pass back to the application for filemarks, setmarks, EOD, and EOM. Either we have to add some error codes or add an MT ioctl so the application can determin what the exact cause of the EIO was. > Let me add, I like SGI's "mt" command. "mt status" is full of all kinds > of useful info (such as tape position, drive manufacturer's model #)and > its output is shorter than FreeBSD's. I like the way SGI blocks on tape > access when the drive is temporarily busy loading tape. I don't like the > nasty message FreeBSD and Solaris deliver. I don't think that the CAM driver will give you the "nasty message" since it will wait for up to a minute for a device to become ready before failing a command assuming the device returns busy status or the "in the process of becoming ready" sense key.. > -- > David Kelly N4HHE, dkelly@nospam.hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-scsi Tue Dec 9 18:47:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA04198 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 18:47:14 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [128.120.56.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA04173 for ; Tue, 9 Dec 1997 18:47:06 -0800 (PST) (envelope-from obrien@NUXI.com) Received: (from obrien@localhost) by relay.nuxi.com (8.8.7/8.6.12) id CAA12279; Wed, 10 Dec 1997 02:46:57 GMT Message-ID: <19971209184656.58962@relay.nuxi.com> Date: Tue, 9 Dec 1997 18:46:56 -0800 From: "David E. O'Brien" To: David Kelly Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: obrien@NUXI.com References: <199712100037.SAA25972@nospam.hiwaay.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199712100037.SAA25972@nospam.hiwaay.net>; from David Kelly on Tue, Dec 09, 1997 at 06:37:39PM -0600 X-Warning: Mutt Bites! X-Operating-System: FreeBSD 2.2.5-STABLE Organization: The NUXI *BSD group X-PGP-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Keyid: 34F9F9D5 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > boss to order the Exabyte manual ($55) but Nobody Has Bothered Yet. I've got a copy of this manual. What things are you interested in (besides the entire thing). Are you in the B.A.? > a couple 8mm Exabyte 8505's. Darn it, those Exabytes sure look nice and > work well on my FreeBSD system. Then your luck is better than mine. My 8505 has mostly been useless on FreeBSD. :-( > I don't like the nasty message FreeBSD and Solaris deliver. So knowing the intimate knowledge of how Solaris 2.4 would handle issues isn't of interest? :-) -- -- David (obrien@NUXI.com -or- obrien@FreeBSD.org) James says: "Grad school sucks." (well... we do get source :-)) From owner-freebsd-scsi Tue Dec 9 21:13:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA16126 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 21:13:07 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA16121 for ; Tue, 9 Dec 1997 21:13:03 -0800 (PST) (envelope-from grog@lemis.com) Received: from papillon.lemis.com ([168.87.69.104]) by Tandem.com (8.8.8/2.0.1) with ESMTP id VAA12398; Tue, 9 Dec 1997 21:12:58 -0800 (PST) Received: (grog@localhost) by papillon.lemis.com (8.8.8/8.6.12) id MAA05655; Wed, 10 Dec 1997 12:44:13 +0800 (CST) Message-ID: <19971210124412.30786@lemis.com> Date: Wed, 10 Dec 1997 12:44:12 +0800 From: Greg Lehey To: obrien@NUXI.com Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem References: <199712100037.SAA25972@nospam.hiwaay.net> <19971209184656.58962@relay.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <19971209184656.58962@relay.nuxi.com>; from David E. O'Brien on Tue, Dec 09, 1997 at 06:46:56PM -0800 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, Dec 09, 1997 at 06:46:56PM -0800, David E. O'Brien wrote: >> a couple 8mm Exabyte 8505's. Darn it, those Exabytes sure look nice and >> work well on my FreeBSD system. > > Then your luck is better than mine. My 8505 has mostly been useless on > FreeBSD. :-( Don't tell me that. I just bought one (-XL) here in Hong Kong. Brand new Sun shoebox, only $600. But I had an 8500 before that, and I didn't have any software trouble with it. What's your problem? Greg From owner-freebsd-scsi Tue Dec 9 23:05:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA22847 for freebsd-scsi-outgoing; Tue, 9 Dec 1997 23:05:43 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA22841 for ; Tue, 9 Dec 1997 23:05:39 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id XAA22478; Tue, 9 Dec 1997 23:05:33 -0800 (PST) Date: Tue, 9 Dec 1997 23:05:33 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199712100705.XAA22478@math.berkeley.edu> To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Cc: dan@math.berkeley.edu Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In SCSI, there is no such thing as an "EOT" marker. Instead, you must Modern SCSI tape systems typically recognize some combination of physical EOT (beyond which you cannot write), logical EOT (beyond which you might be able to write if you know the magic commands), and EOM (after the most recently written record on a sequential access tape). The details depend mainly on the exact medium and somewhat on the drive. I don't remember how much of this is standardized in the various versions of SCSI. > The Berkeley convention was that 2 filemarks in a row signaled EOT. This convention (which as far as I know did not originate at UCB) predates all flavors of Unix. It was a really simple and convenient device and OS independent convention for marking the end of data. It did have the disadvantage that it discouraged empty files and it was finally broken by modern cheap tape drives that were not able to overwrite EOF marks. My personal policy (in writing tape drivers) is that all drivers for tapes that are capable of overwritting EOF marks should write a double EOF and then backspace before closing the device or doing any tape motion operation if the previous tape operation was a write. For drives that are not capable of overwriting EOF marks, I favor the convention that a single EOF mark (with no backspace) be written in these circumstances and that a double EOF mark be written before rewinds (even though this may inconvenience lazy programmers who don't think ahead). Of course, nobody ever listens to me ... :-) > Right now, we only have a single error code to pass back to the application > for filemarks, setmarks, EOD, and EOM. Either we have to add some error > codes or add an MT ioctl so the application can determin what the exact > cause of the EIO was. The convention that a raw tape driver return a single zero length read to mark EOF is very ancient and should be respected because it is so darn useful. It means that a program can distinguish between a read error and an end of file without knowing specific error codes. I would rather not see that convention change just because some tape drivers were written by people who were too green to know the convention or were unable to appreciate its value. I think we should strive to do the "right" thing even though major OS vendors do it wrong. Dan Strick dan@math.berkeley.edu From owner-freebsd-scsi Wed Dec 10 00:25:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA28047 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 00:25:46 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA28040 for ; Wed, 10 Dec 1997 00:25:42 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.7/8.7.3) id BAA19029; Wed, 10 Dec 1997 01:23:59 -0700 (MST) Date: Wed, 10 Dec 1997 01:23:59 -0700 (MST) Message-Id: <199712100823.BAA19029@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712100705.XAA22478@math.berkeley.edu> In-Reply-To: <199712100705.XAA22478@math.berkeley.edu> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: Questions about mt and SCSI subsystem X-Original-Newsgroups: pluto.freebsd.scsi To: dan@math.berkeley.edu (Dan Strick) cc: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <199712100705.XAA22478@math.berkeley.edu>, dan@math.berkeley.edu (Dan Strick) writes: >> In SCSI, there is no such thing as an "EOT" marker. Instead, you must > > Modern SCSI tape systems typically recognize some combination of > physical EOT (beyond which you cannot write), logical EOT (beyond > which you might be able to write if you know the magic commands), > and EOM (after the most recently written record on a sequential > access tape). The details depend mainly on the exact medium and > somewhat on the drive. I don't remember how much of this is > standardized in the various versions of SCSI. This doesn't quite jibe with either the SCSI II or SCSI III spec. Essentially they define three different terms: EOD - End of data in a partition is denoted in a format-specific manner. EOM - The extreme position along the medium in the direction away from the take-up reel which can be accessd by the device. This position may be accessed by devices that support the LOAD UNLOAD command with the EOT bit set to one. EOP - The position at the end of the permissible recording region of a partition. In respects to a read, you can be notified for: 1) A filemark being read. 2) A setmark being read. 3) hitting early warning. 4) hitting EOD (if the drive supports recognizing EOD). 5) hitting EOP Both EOD and EOP set the logical "EOM" flag in the status you get returned. > My personal policy (in writing tape drivers) is that all drivers for > tapes that are capable of overwritting EOF marks should write a double > EOF and then backspace before closing the device or doing any tape motion > operation if the previous tape operation was a write. Backspace a single filemark, correct? > For drives > that are not capable of overwriting EOF marks, I favor the convention > that a single EOF mark (with no backspace) be written in these > circumstances and that a double EOF mark be written before rewinds > (even though this may inconvenience lazy programmers who don't think > ahead). You favor this even if the media is specified to have a different EOD convention... perhaps even one that the drive writes on your behalf? > Of course, nobody ever listens to me ... :-) > >> Right now, we only have a single error code to pass back to the application >> for filemarks, setmarks, EOD, and EOM. Either we have to add some error >> codes or add an MT ioctl so the application can determin what the exact >> cause of the EIO was. > > The convention that a raw tape driver return a single zero length > read to mark EOF is very ancient and should be respected because it > is so darn useful. It means that a program can distinguish between > a read error and an end of file without knowing specific error codes. I shouldn't have included filemarks in my statement. This behavior is aintained in both versions of the driver. > I would rather not see that convention change just because some > tape drivers were written by people who were too green to know the > convention or were unable to appreciate its value. > > I think we should strive to do the "right" thing even though major > OS vendors do it wrong. I'm all for doing it right so long as I can read tapes that were written using a different vendor's OS and they can read my tapes too. > Dan Strick > dan@math.berkeley.edu -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Dec 10 00:52:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29362 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 00:52:12 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29355 for ; Wed, 10 Dec 1997 00:52:08 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA05764 for scsi@FreeBSD.ORG; Wed, 10 Dec 1997 09:52:06 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA07713; Wed, 10 Dec 1997 09:37:32 +0100 (MET) Message-ID: <19971210093732.48185@uriah.heep.sax.de> Date: Wed, 10 Dec 1997 09:37:32 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712100243.TAA18226@narnia.plutotech.com>; from Justin T. Gibbs on Tue, Dec 09, 1997 at 07:43:28PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > The FreeBSD st driver (including the CAM one), > return EIO when a filemark is encountered or a "blank check" is reported. > It's up to the reading program to decide what that means. This is wrong. It breaks the normal conventions for read(2) that say encountering EOF upon a read request should terminate the request with an appropriate return value (possibly 0 bytes read), but with no error condition. As such, it breaks the EOF detection in dump(8). Of course, returning EIO afterwards is appropriate. > Assuming the device supports the READ POSITION scsi command, there's no > reason we can't add this feature to mt/sa(4). Unfortunately, READ POSITION only reports block numbers, but not tape file numbers. A block number is rather useless for most people, while many are interested in the current tape file number. We have to count the filemarks manually in the driver, i'm afraid. (I've been playing with READ POSITION a little.) -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Dec 10 00:52:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id AAA29414 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 00:52:26 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id AAA29401 for ; Wed, 10 Dec 1997 00:52:20 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id JAA05772 for scsi@FreeBSD.ORG; Wed, 10 Dec 1997 09:52:16 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id JAA07742; Wed, 10 Dec 1997 09:46:20 +0100 (MET) Message-ID: <19971210094619.54824@uriah.heep.sax.de> Date: Wed, 10 Dec 1997 09:46:19 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100705.XAA22478@math.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712100705.XAA22478@math.berkeley.edu>; from Dan Strick on Tue, Dec 09, 1997 at 11:05:33PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Dan Strick wrote: > For drives > that are not capable of overwriting EOF marks, I favor the convention > that a single EOF mark (with no backspace) be written in these > circumstances and that a double EOF mark be written before rewinds > (even though this may inconvenience lazy programmers who don't think > ahead). Still, this would break appending to the tape, where it leaves the double EOF. > The convention that a raw tape driver return a single zero length > read to mark EOF is very ancient and should be respected because it > is so darn useful. Right he is! Note that this convention doesn't only apply to tape devices, it applies to any Unix device. It was handled rather sloppy in FreeBSD, it's not that long ago that i've fixed the floppy disk driver's EOF handling. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Dec 10 13:30:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA20849 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 13:30:38 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA20838 for ; Wed, 10 Dec 1997 13:30:34 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id NAA02639; Wed, 10 Dec 1997 13:28:13 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd002637; Wed Dec 10 13:28:13 1997 Message-ID: <348F08D6.63DABEB6@whistle.com> Date: Wed, 10 Dec 1997 13:25:43 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: Joerg Wunsch CC: scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'd offer to fix it if I could be told what he right thing to do is.. but I don't have a tape drive here at all.. J Wunsch wrote: > As Justin T. Gibbs wrote:> > > The FreeBSD st driver (including the CAM one), > > return EIO when a filemark is encountered or a "blank check" is reported. > > It's up to the reading program to decide what that means. > > This is wrong. It breaks the normal conventions for read(2) that say > encountering EOF upon a read request should terminate the request with > an appropriate return value (possibly 0 bytes read), but with no error > condition. As such, it breaks the EOF detection in dump(8). > > Of course, returning EIO afterwards is appropriate. > > > Assuming the device supports the READ POSITION scsi command, there's no > > reason we can't add this feature to mt/sa(4). > > Unfortunately, READ POSITION only reports block numbers, but not tape > file numbers. A block number is rather useless for most people, while > many are interested in the current tape file number. We have to count > the filemarks manually in the driver, i'm afraid. > > (I've been playing with READ POSITION a little.) > > -- > cheers, J"org > > joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE > Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Dec 10 14:06:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA23504 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 14:06:50 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from mail.jump.net (serv1.jump.net [204.238.120.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA23499; Wed, 10 Dec 1997 14:06:46 -0800 (PST) (envelope-from aa@jump.net) Received: from rat by mail.jump.net (8.8.8/jump.1.11) id PAA20656; Message-ID: <348F0FB9.C6C@jump.net> Date: Wed, 10 Dec 1997 15:55:05 -0600 From: Allan Alford X-Mailer: Mozilla 3.04Gold (Win95; I) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org CC: freebsd-scsi@freebsd.org Subject: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Howdy! This is my first post to either of these lists, so I hope this is the right place for this kind of thing. I recently purchased one of the above-mentioned drives and put it into an external SCSI cabinet. I also bought a 1.2 Gig QIC-1000 tape (the largest the manufacturer recommends). Now I'm having problems putting this thing to good use. Since it's a 1/4" tape, the concatenate and append flags on tar don't seem to work. Trying to tar multiple directories fails as a result. Referencing the device as /dev/nrst0 does not seem to help either. Dumping a 496meg file system reports that I need 10.2 tapes! Tarring the same file system works just fine however. Can anyone offer any help? Is it normal that I would need to mess with the density and feet settings on dump? Is it normal that tar would use the tape correctly while dump wouldn't? Most importantly: How do I get the tape to accept multiple dumps and/or tars? I can't seem to set it to no rewind. Also, how do I access the details of this "Rogue's Gallery" that I keep seeing reference to in the man pages? Thanks for any and all help, Allan Alford From owner-freebsd-scsi Wed Dec 10 16:23:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08573 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 16:23:10 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08492 for ; Wed, 10 Dec 1997 16:22:48 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA15523 for scsi@freebsd.org; Thu, 11 Dec 1997 01:22:45 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA09340; Thu, 11 Dec 1997 00:59:05 +0100 (MET) Message-ID: <19971211005904.40551@uriah.heep.sax.de> Date: Thu, 11 Dec 1997 00:59:04 +0100 From: J Wunsch To: scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <348F08D6.63DABEB6@whistle.com>; from Julian Elischer on Wed, Dec 10, 1997 at 01:25:43PM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Julian Elischer wrote: > I'd offer to fix it if I could be told what he right thing to do is.. > but I don't have a tape drive here at all.. It's probably hard to fix without having a tape drive -- i gave up fixing it even with a drive. ;-) The correct behaviour is that any read or write attempt, upon encountering EOF (read) or EOM (write) should return a `short' read/write (i.e., set b_resid accordingly), but shall not flag an error condition. Offhand i'm not sure what should happen if you are exactly at EOF, and try to read on, but still i think read(2) should just return 0 but no error. Basically, you need to be consistent with normal file IO (although there's no such thing like `EOM' for writing files). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Dec 10 16:23:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA08615 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 16:23:21 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA08475; Wed, 10 Dec 1997 16:22:41 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id BAA15520; Thu, 11 Dec 1997 01:22:32 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id BAA09393; Thu, 11 Dec 1997 01:15:08 +0100 (MET) Message-ID: <19971211011508.60795@uriah.heep.sax.de> Date: Thu, 11 Dec 1997 01:15:08 +0100 From: J Wunsch To: Allan Alford Cc: freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 Reply-To: Joerg Wunsch References: <348F0FB9.C6C@jump.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <348F0FB9.C6C@jump.net>; from Allan Alford on Wed, Dec 10, 1997 at 03:55:05PM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Allan Alford wrote: > Since it's a 1/4" tape, the concatenate and append flags on tar don't > seem to work. Trying to tar multiple directories fails as a result. > > Referencing the device as /dev/nrst0 does not seem to help either. How exactly do you do it? It works for me. > Dumping a 496meg file system reports that I need 10.2 tapes! Dumps defaults are stupid. Use `dump -a' instead (but beware, EOF detection is currently broken, there's an open PR for this). -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Wed Dec 10 19:29:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA25376 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 19:29:49 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA25357 for ; Wed, 10 Dec 1997 19:29:45 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id UAA17646; Wed, 10 Dec 1997 20:27:55 -0700 (MST) Date: Wed, 10 Dec 1997 20:27:55 -0700 (MST) Message-Id: <199712110327.UAA17646@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> In-Reply-To: <19971211005904.40551@uriah.heep.sax.de> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: Questions about mt and SCSI subsystem X-Original-Newsgroups: pluto.freebsd.scsi To: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <19971211005904.40551@uriah.heep.sax.de>, J Wunsch writes: > > The correct behaviour is that any read or write attempt, upon > encountering EOF (read) or EOM (write) should return a `short' > read/write (i.e., set b_resid accordingly), but shall not flag an > error condition. Are you sure about the behavior for write? > Offhand i'm not sure what should happen if you are exactly at EOF, > and try to read on, but still i think read(2) should just return 0 but > no error. On a tape, you will start reading the next file unless the EOF handling back spaces over the filemark after noticing it. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-scsi Wed Dec 10 20:58:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA02112 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 20:58:54 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from mail.jump.net (serv1.jump.net [204.238.120.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA02098; Wed, 10 Dec 1997 20:58:46 -0800 (PST) (envelope-from aa@jump.net) Received: from bubba by mail.jump.net (8.8.8/jump.1.11) id WAA24265; Message-ID: <348F72F6.6B37@jump.net> Date: Wed, 10 Dec 1997 22:58:30 -0600 From: Allan Alford X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: freebsd-hardware@FreeBSD.ORG CC: freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 References: <348F0FB9.C6C@jump.net> <19971211011508.60795@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > How exactly do you do it? It works for me. > I've been using the following syntax in my script: tar -cv /dev/nrst0 /foo tar -cv /dev/nrst0 /bar tar -cv /dev/nrst0 /foobar When I check the tape the next morning, I do: mt rewind (tape already seems to be rewound) tar -tv (yields the tar of foobar - the last from the list) mt fsf 1 (nothing seems to happen) tar -tv (yields the tar of foobar - the last from the list) Is there a quicker way to test and make sure that the /nrst0 device really is no rewind? Some way to copy something directly, perhaps? cpio, maybe? I've only ever worked with DAT in the past and have never had these problems. > > Dumping a 496meg file system reports that I need 10.2 tapes! > > Dumps defaults are stupid. Use `dump -a' instead (but beware, EOF > detection is currently broken, there's an open PR for this). Other folks recommended this strategy. I will try this one in the morning. Thank you all for your help. Also, Joerg, since you seem to know the particular device, I have one last question: The docs indicate that I can jump the 51000HT to be either SCSI-1 or SCSI-2 and yet the jumper maps show no such jumper. Currently, I'm SCSI 1. Do you know how to set this? = allan From owner-freebsd-scsi Wed Dec 10 22:13:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA06755 for freebsd-scsi-outgoing; Wed, 10 Dec 1997 22:13:38 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from Tandem.com (suntan.tandem.com [192.216.221.8]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA06745; Wed, 10 Dec 1997 22:13:36 -0800 (PST) (envelope-from grog@lemis.com) Received: from papillon.lemis.com ([168.87.69.104]) by Tandem.com (8.8.8/2.0.1) with ESMTP id WAA08818; Wed, 10 Dec 1997 22:13:30 -0800 (PST) Received: (grog@localhost) by papillon.lemis.com (8.8.8/8.6.12) id OAA08467; Thu, 11 Dec 1997 14:00:12 +0800 (CST) Message-ID: <19971211140011.44835@lemis.com> Date: Thu, 11 Dec 1997 14:00:11 +0800 From: Greg Lehey To: Allan Alford Cc: freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 References: <348F0FB9.C6C@jump.net> <19971211011508.60795@uriah.heep.sax.de> <348F72F6.6B37@jump.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: <348F72F6.6B37@jump.net>; from Allan Alford on Wed, Dec 10, 1997 at 10:58:30PM -0600 Organisation: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, Dec 10, 1997 at 10:58:30PM -0600, Allan Alford wrote: > J Wunsch wrote: > >> How exactly do you do it? It works for me. >> > > I've been using the following syntax in my script: > > tar -cv /dev/nrst0 /foo > tar -cv /dev/nrst0 /bar > tar -cv /dev/nrst0 /foobar > > When I check the tape the next morning, I do: > > mt rewind > (tape already seems to be rewound) > tar -tv > (yields the tar of foobar - the last from the list) > mt fsf 1 > (nothing seems to happen) > tar -tv > (yields the tar of foobar - the last from the list) > > Is there a quicker way to test and make sure that the /nrst0 device > really is no rewind? Some way to copy something directly, perhaps? > > cpio, maybe? I've only ever worked with DAT in the past and have > never had these problems. I do pretty much exactly this for my nightly backup, and it works fine. I'd guess that this is a driver bug, not a tar bug. Greg From owner-freebsd-scsi Thu Dec 11 01:13:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22237 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 01:13:58 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from mailhub (tfs.com [140.145.250.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id BAA22210; Thu, 11 Dec 1997 01:13:53 -0800 (PST) (envelope-from fj@schizo.dk.tfs.com) Received: from schizo.dk.tfs.com by mailhub (SMI-8.6/SMI-SVR4) id BAA06901; Thu, 11 Dec 1997 01:06:56 -0800 Received: (from fj@localhost) by schizo.dk.tfs.com (8.8.7/8.7.3) id KAA21898; Thu, 11 Dec 1997 10:13:18 +0100 (MET) From: Flemming Jacobsen Message-Id: <199712110913.KAA21898@schizo.dk.tfs.com> Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 In-Reply-To: <348F72F6.6B37@jump.net> from Allan Alford at "Dec 10, 97 10:58:30 pm" To: aa@jump.net (Allan Alford) Date: Thu, 11 Dec 1997 10:13:17 +0100 (MET) Cc: freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi world, > I've been using the following syntax in my script: > > tar -cv /dev/nrst0 /foo > tar -cv /dev/nrst0 /bar > tar -cv /dev/nrst0 /foobar Uhmmmm, you DO mean 'tar -cvf /dev/nrst0 /foo', right? Otherwise your problem is pretty obvious - tar defaults to use /dev/rst0 (but a backup of the /dev/nrst0 device is allways nice ;-). I realize that the missing 'f' probably is a typo. OTOH it would account for the behaviour that you see. > When I check the tape the next morning, I do: > > mt rewind > (tape already seems to be rewound) > tar -tv > (yields the tar of foobar - the last from the list) > mt fsf 1 > (nothing seems to happen) > tar -tv > (yields the tar of foobar - the last from the list) Have a nice day Flemming -- Flemming Jacobsen It'll probably say something like "Does not TRW Financial Systems, Denmark compute" or "Inoperative parameters". That's Email: fj@tfs.com what it says when it doesn't know and doesn't Phone: +45 4330 4050 want to admit it. -- Terry Pratchett: Wings From owner-freebsd-scsi Thu Dec 11 01:15:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA22366 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 01:15:00 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA22355 for ; Thu, 11 Dec 1997 01:14:57 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA19627 for scsi@FreeBSD.ORG; Thu, 11 Dec 1997 10:14:36 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id KAA12050; Thu, 11 Dec 1997 10:10:03 +0100 (MET) Message-ID: <19971211101003.17782@uriah.heep.sax.de> Date: Thu, 11 Dec 1997 10:10:03 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> <199712110327.UAA17646@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712110327.UAA17646@narnia.plutotech.com>; from Justin T. Gibbs on Wed, Dec 10, 1997 at 08:27:55PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > > The correct behaviour is that any read or write attempt, upon > > encountering EOF (read) or EOM (write) should return a `short' > > read/write (i.e., set b_resid accordingly), but shall not flag an > > error condition. > > Are you sure about the behavior for write? Yep. dump and multivolume tar rely on this behaviour, that's why dump -a is currently broken. (*) It gets an EIO at the end of the tape, and assumes something went wrong with writing the last block, so instead of asking for the next tape (which it would have done upon write() returning 0), it asks to replace the same tape again, and wants to write this one once more. Note that, while dump -a is my invention, the algorithm to detect the end of tape has been there all the time; dump -a only enforces the use of this algorithm over some tape length calculations. (*) It was broken for (almost?) all disk and tape devices in FreeBSD. People have been complaining about not being able to write multivolume floppy tar archives, that finally made me fixing the floppy driver. I'm not sure about sd(4) (and all the derived drivers), whether they do it right or not. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Dec 11 01:23:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA23167 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 01:23:07 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA23140; Thu, 11 Dec 1997 01:22:50 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id KAA19698; Thu, 11 Dec 1997 10:22:25 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id KAA12273; Thu, 11 Dec 1997 10:17:23 +0100 (MET) Message-ID: <19971211101723.12170@uriah.heep.sax.de> Date: Thu, 11 Dec 1997 10:17:23 +0100 From: J Wunsch To: Allan Alford Cc: freebsd-hardware@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 Reply-To: Joerg Wunsch References: <348F0FB9.C6C@jump.net> <19971211011508.60795@uriah.heep.sax.de> <348F72F6.6B37@jump.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <348F72F6.6B37@jump.net>; from Allan Alford on Wed, Dec 10, 1997 at 10:58:30PM -0600 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Allan Alford wrote: > > How exactly do you do it? It works for me. > > > > I've been using the following syntax in my script: > > tar -cv /dev/nrst0 /foo > tar -cv /dev/nrst0 /bar > tar -cv /dev/nrst0 /foobar Well, therein lies the rub. :) You've been using the (default) rewind-on-close device all the time, but tried to backup the device node /dev/nrst0 as the first file in each archive. tar -cvf /dev/nrst0 /foo tar -cvf /dev/nrst0 /bar > mt rewind > (tape already seems to be rewound) > tar -tv This must be tar -tvf /dev/nrst0 again. Alternatively, you can set the env variable TAPE to it. (Note that mt(1) uses /dev/nrst0 by default -- it wouldn't make much sense otherwise.) > Also, Joerg, since you seem to know the particular device, I have > one last question: No, i don't know this particular device. > The docs indicate that I can jump the 51000HT to be either SCSI-1 or > SCSI-2 and yet the jumper maps show no such jumper. Currently, I'm > SCSI 1. Do you know how to set this? Dunno, but it'll probably only change the way it announces itself in the INQUIRY command. I don't think the drive will behave differently otherwise, so: ``Don't worry''. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Dec 11 05:27:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA11676 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 05:27:32 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id FAA11657 for ; Thu, 11 Dec 1997 05:27:27 -0800 (PST) (envelope-from bde@zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.6.9) id AAA10223; Fri, 12 Dec 1997 00:20:52 +1100 Date: Fri, 12 Dec 1997 00:20:52 +1100 From: Bruce Evans Message-Id: <199712111320.AAA10223@godzilla.zeta.org.au> To: j@uriah.heep.sax.de, scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> > The correct behaviour is that any read or write attempt, upon >> > encountering EOF (read) or EOM (write) should return a `short' >> > read/write (i.e., set b_resid accordingly), but shall not flag an >> > error condition. >> >> Are you sure about the behavior for write? >Yep. dump and multivolume tar rely on this behaviour, that's why dump >-a is currently broken. (*) It gets an EIO at the end of the tape, Actually, tar relies on (near) EOF being handled in one of the follow ways: 1. write() returns < 0, with (a) errno == ENOSPC, or (b) errno == EIO, or (c) errno == ENXIO (braindamage for "the UNIX PC"). 2. write() returns 0 (EOF). 3. write() returns > 0 but < the size requested. 1(a) is best at full EOF. (2) is equivalent except more applications mishandle it. 1(a) is what happens for a write to a regular file when the disk fills up, so all applications should handle it. (3) is best if EOF occurs in the middle of the write - it's not reasonable to return ENOSPC since there is no general interface for determining a size that would fit (other than attempting a write()). dump seems to prefer (2), but it has some support for ENOSPC on "Pyramids running OSx". dd seems to prefer (2) too. >and assumes something went wrong with writing the last block, so >instead of asking for the next tape (which it would have done upon >write() returning 0), it asks to replace the same tape again, and >wants to write this one once more. Note that, while dump -a is my >invention, the algorithm to detect the end of tape has been there all >the time; dump -a only enforces the use of this algorithm over some >tape length calculations. Perhaps it needs to be more general now that it is actually used :-) >(*) It was broken for (almost?) all disk and tape devices in FreeBSD. >People have been complaining about not being able to write multivolume >floppy tar archives, that finally made me fixing the floppy driver. >I'm not sure about sd(4) (and all the derived drivers), whether they >do it right or not. I think it is still broken in most cases. dscheck() sets bp->b_error = EINVAL instead of ENOSPC. cdrom drivers use ad hoc EOF handling. E.g., wcdstrategy() does no bounds checking and probably sets bp->b_error = EIO if the h/w fails properly. This only breaks reading of course. While investigating this, I found that ftruncate() on an fd for /dev/rfd0 does bad vnode operations and soon panics in spec_strategy(). spec_truncate() used to be null, but ffs_truncate() now gets called. The stack trace at the panic was disgustingly deep, something like the following one for pagefaults: spec_strategy spec_vnoperate ufs_vnoperatespec spec_getpages spec_vnoperate ufs_vnoperatespec ffs_getpages vnode_pager_getpages vm_pager_get_pages vm_fault trap_pfault trap calltrap --- trap 0xc Bruce From owner-freebsd-scsi Thu Dec 11 08:08:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA22618 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 08:08:25 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA22607 for ; Thu, 11 Dec 1997 08:08:22 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id IAA19183; Thu, 11 Dec 1997 08:08:16 -0800 (PST) Date: Thu, 11 Dec 1997 08:08:16 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199712111608.IAA19183@math.berkeley.edu> To: gibbs@narnia.plutotech.com Subject: Re: Questions about mt and SCSI subsystem Cc: dan@math.berkeley.edu, scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > My personal policy (in writing tape drivers) is that all drivers for > > tapes that are capable of overwriting EOF marks should write a double > > EOF and then backspace before closing the device or doing any tape motion > > operation if the previous tape operation was a write. > > Backspace a single filemark, correct? correct > > For drives > > that are not capable of overwriting EOF marks, I favor the convention > > that a single EOF mark (with no backspace) be written in these > > circumstances and that a double EOF mark be written before rewinds > > (even though this may inconvenience lazy programmers who don't think > > ahead). > > You favor this even if the media is specified to have a different EOD > convention... perhaps even one that the drive writes on your behalf? Yes. Programs that read tapes should know as little as possible about specific kinds of tape drives. In particular, they should not have to know SCSI error codes. Note that not all SCSI tape drives support any sort of end-of-recording recognition. Some just return a data error. > > The convention that a raw tape driver return a single zero length I should have been more explicit. A tape driver should return a single zero-length-read to indicate EOF. The next read should return the first record of the next file on the tape (or nothing for another EOF). Some modern tape drivers will stop at EOF and return zero length reads until you close and reopen the device. This is wrong. I suspect that someone wrote a driver that did it wrong (either due to ignorance or because doing it right is more difficult in fixed-length block mode) and then the OS vendor "fixed" the problem by declaring this behavior to be a feature. I don't know what the FreeBSD SCSI system does. It might well do this correctly. This tirade is really about SCSI drivers in general and not about the FreeBSD's SCSI driver. Dan Strick dan@math.berkeley.edu From owner-freebsd-scsi Thu Dec 11 08:41:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA24671 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 08:41:20 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from math.berkeley.edu (math.Berkeley.EDU [128.32.183.94]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA24664 for ; Thu, 11 Dec 1997 08:41:15 -0800 (PST) (envelope-from dan@math.berkeley.edu) Received: (from dan@localhost) by math.berkeley.edu (8.8.7/8.8.7) id IAA20249; Thu, 11 Dec 1997 08:41:03 -0800 (PST) Date: Thu, 11 Dec 1997 08:41:03 -0800 (PST) From: dan@math.berkeley.edu (Dan Strick) Message-Id: <199712111641.IAA20249@math.berkeley.edu> To: joerg_wunsch@uriah.heep.sax.de Subject: Re: Questions about mt and SCSI subsystem Cc: dan@math.berkeley.edu, scsi@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > For drives > > that are not capable of overwriting EOF marks, I favor the convention > > that a single EOF mark (with no backspace) be written in these > > circumstances and that a double EOF mark be written before rewinds > > (even though this may inconvenience lazy programmers who don't think > > ahead). > > Still, this would break appending to the tape, where it leaves the > double EOF. Yes, it would inconvenience those lazy programmers who don't think ahead. > > The convention that a raw tape driver return a single zero length > > read to mark EOF is very ancient and should be respected because it > > is so darn useful. > > Right he is! Note that this convention doesn't only apply to tape > devices, it applies to any Unix device. It was handled rather sloppy > in FreeBSD, it's not that long ago that i've fixed the floppy disk > driver's EOF handling. I think of that more as a different convention specifically for random access devices. A read that begins (at least one byte) beyond the end of the device (or disk partition) should return -1 with error code ENXIO. A read that begins at or before the end of the device and extends past the end of the device (or partition) should return the available data without error (i.e. do a short read). In my opinion, short writes should not be allowed. The driver should return an error in such circumstances. The man page for write(2) in the Unix Sixth Edition manual did in fact require this. Somewhere in between then and now that requirement was relaxed, but it would still seem to apply to disk writes. Dan Strick dan@math.berkeley.edu From owner-freebsd-scsi Thu Dec 11 09:21:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA27622 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 09:21:08 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from mail.jump.net (serv1.jump.net [204.238.120.4]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA27592; Thu, 11 Dec 1997 09:20:55 -0800 (PST) (envelope-from aa@jump.net) Received: from rat by mail.jump.net (8.8.8/jump.1.11) id LAA28864; Message-ID: <349020BD.321@jump.net> Date: Thu, 11 Dec 1997 11:19:57 -0600 From: Allan Alford X-Mailer: Mozilla 3.04Gold (Win95; I) MIME-Version: 1.0 To: freebsd-scsi@freebsd.org CC: freebsd-hardware@freebsd.org Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 References: <199712110913.KAA21898@schizo.dk.tfs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Flemming Jacobsen wrote: > > Hi world, > > > I've been using the following syntax in my script: > > > > tar -cv /dev/nrst0 /foo > > tar -cv /dev/nrst0 /bar > > tar -cv /dev/nrst0 /foobar > > Uhmmmm, you DO mean 'tar -cvf /dev/nrst0 /foo', right? Otherwise > your problem is pretty obvious - tar defaults to use /dev/rst0 > (but a backup of the /dev/nrst0 device is allways nice ;-). > I realize that the missing 'f' probably is a typo. OTOH it would > account for the behaviour that you see. > And the winner of the Bonehead of the Month Award Is.... Me! Arguments? We don't need no stinkin' arguments! Heh. - Allan From owner-freebsd-scsi Thu Dec 11 09:48:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA00189 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 09:48:53 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from vina-tech.com (vina-tech.com [207.242.96.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA00182 for ; Thu, 11 Dec 1997 09:48:47 -0800 (PST) (envelope-from scott.watters@vina-tech.com) Received: from curious (curious.vina-tech.com [207.242.96.69]) by vina-tech.com (8.8.7/8.8.7) with SMTP id JAA12020 for ; Thu, 11 Dec 1997 09:47:26 -0800 (PST) (envelope-from scott.watters@vina-tech.com) Message-ID: <003901bd065c$c0525120$4560f2cf@curious.vina-tech.com> Reply-To: "Scott Watters" From: "Scott Watters" To: Subject: Yet another SCSI tape driver question Date: Thu, 11 Dec 1997 09:46:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I appreciate all the discussion about the problems with the current tape subsystem. I believe most of the discussion has been about handling EOF with read and write. I'd like to bring up the main problem I am having which is behavior of skipping file marks at EOD (end of recorded data). What should the behavior be if the tape has reached EOD (how that is marked, I don't care, but 2 EOFs seems good) and a request for skip forward file mark (or block I guess) is received? I would assume an error should be reported. The current action is 0 is returned and the driver logs an error (BLANK CHECK). Thanks, Scott Watters scott.watters@vina-tech.com http://www.vina-tech.com From owner-freebsd-scsi Thu Dec 11 09:50:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA00296 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 09:50:16 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from indy3.gstone.com ([199.35.226.23]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA00288 for ; Thu, 11 Dec 1997 09:50:12 -0800 (PST) (envelope-from walcaraz@indy3.gstone.com) Received: from raistlin (raistlin.gstone.com [199.35.226.192]) by indy3.gstone.com (8.8.5/8.8.3) with SMTP id JAA21704 for ; Thu, 11 Dec 1997 09:45:49 -0800 (PST) Message-ID: <005801bd065d$28dae040$c0e223c7@raistlin.gstone.com> Reply-To: "Walter .S. Alcaraz" From: "Walter .S. Alcaraz" To: Subject: RAID on FreeBSD Date: Thu, 11 Dec 1997 09:49:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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 Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I plan on purchasing FreeBSD 2.2.5 and installing it on a Pentium 200 or Pentium II 233 with 32 MB RAM. I want to run it as an NFS server with 32 GB storage and a 100-mbit Fast Ethernet card, running with a RAID Ultra-Wide SCSI controller. The setup I want to use is 9 4 GB Ultra-Wide SCSI drives, with a RAID controller doing RAID level 5. My question is, which RAID SCSI controller does FreeBSD support and what one works the best? From owner-freebsd-scsi Thu Dec 11 10:56:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA04857 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 10:56:02 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id KAA04830 for ; Thu, 11 Dec 1997 10:55:59 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xgDcH-0004aq-00; Thu, 11 Dec 1997 10:45:45 -0800 Date: Thu, 11 Dec 1997 10:45:43 -0800 (PST) From: Tom To: "Walter .S. Alcaraz" cc: freebsd-scsi@freebsd.org Subject: Re: RAID on FreeBSD In-Reply-To: <005801bd065d$28dae040$c0e223c7@raistlin.gstone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Walter .S. Alcaraz wrote: > I plan on purchasing FreeBSD 2.2.5 and installing it on a Pentium 200 or > Pentium II 233 with 32 MB RAM. I want to run it as an NFS server with 32 GB > storage and a 100-mbit Fast Ethernet card, running with a RAID Ultra-Wide SCSI > controller. The setup I want to use is 9 4 GB Ultra-Wide SCSI drives, with a > RAID controller doing RAID level 5. My question is, which RAID SCSI controller > does FreeBSD support and what one works the best? The DPT PM334UW works well, but you need to install the driver yourself. This card supports up to 64MB cache, and you can add additional channels to it via a daughtercard (up to 3 UW channels in total). You will probably want at least two channels. 9 drives in an uncomfortable number for RAID5. Probably better to go with 10 drives instead, and make two 5 drive arrays. Tom From owner-freebsd-scsi Thu Dec 11 11:02:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA05524 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 11:02:08 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA05515 for ; Thu, 11 Dec 1997 11:02:04 -0800 (PST) (envelope-from gibbs@narnia.plutotech.com) Received: (from gibbs@localhost) by narnia.plutotech.com (8.8.8/8.7.3) id MAA00518; Thu, 11 Dec 1997 12:00:02 -0700 (MST) Date: Thu, 11 Dec 1997 12:00:02 -0700 (MST) Message-Id: <199712111900.MAA00518@narnia.plutotech.com> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> <199712110327.UAA17646@narnia.plutotech.com> <19971211101003.17782@uriah.heep.sax.de> In-Reply-To: <19971211101003.17782@uriah.heep.sax.de> From: gibbs@narnia.plutotech.com (Justin T. Gibbs) Subject: Re: Questions about mt and SCSI subsystem X-Original-Newsgroups: pluto.freebsd.scsi To: Joerg Wunsch cc: scsi@FreeBSD.org Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk In article <19971211101003.17782@uriah.heep.sax.de>, J Wunsch writes: > As Justin T. Gibbs wrote: > >> > The correct behaviour is that any read or write attempt, upon >> > encountering EOF (read) or EOM (write) should return a `short' >> > read/write (i.e., set b_resid accordingly), but shall not flag an >> > error condition. >> >> Are you sure about the behavior for write? > > Yep. dump and multivolume tar rely on this behaviour, that's why dump > -a is currently broken. (*) It gets an EIO at the end of the tape, > and assumes something went wrong with writing the last block, so > instead of asking for the next tape (which it would have done upon > write() returning 0), it asks to replace the same tape again, and > wants to write this one once more. Note that, while dump -a is my > invention, the algorithm to detect the end of tape has been there all > the time; dump -a only enforces the use of this algorithm over some > tape length calculations. It shouldn't return ENOSPC? This error code is documented in write.2. I agree that EIO is incorrect. -- Justin T. Gibbs =========================================== FreeBSD - Turning PCs into workstations =========================================== From owner-freebsd-scsi Thu Dec 11 13:12:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA15639 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 13:12:52 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id NAA15618 for ; Thu, 11 Dec 1997 13:12:46 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA23873 (5.67b/IDA-1.5 for scsi@FreeBSD.ORG); Thu, 11 Dec 1997 22:11:29 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id UAA08924; Thu, 11 Dec 1997 20:50:30 +0100 (MET) From: Wilko Bulte Message-Id: <199712111950.UAA08924@yedi.iaf.nl> Subject: Re: Questions about mt and SCSI subsystem To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 11 Dec 1997 20:50:29 +0100 (MET) Cc: scsi@FreeBSD.ORG In-Reply-To: <19971211101003.17782@uriah.heep.sax.de> from "J Wunsch" at Dec 11, 97 10:10:03 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As J Wunsch wrote... > As Justin T. Gibbs wrote: > > > > The correct behaviour is that any read or write attempt, upon > > > encountering EOF (read) or EOM (write) should return a `short' > > > read/write (i.e., set b_resid accordingly), but shall not flag an > > > error condition. > > > > Are you sure about the behavior for write? > > Yep. dump and multivolume tar rely on this behaviour, that's why dump > -a is currently broken. (*) It gets an EIO at the end of the tape, > and assumes something went wrong with writing the last block, so > instead of asking for the next tape (which it would have done upon > write() returning 0), it asks to replace the same tape again, and > wants to write this one once more. Note that, while dump -a is my > invention, the algorithm to detect the end of tape has been there all > the time; dump -a only enforces the use of this algorithm over some > tape length calculations. > > (*) It was broken for (almost?) all disk and tape devices in FreeBSD. > People have been complaining about not being able to write multivolume > floppy tar archives, that finally made me fixing the floppy driver. > I'm not sure about sd(4) (and all the derived drivers), whether they > do it right or not. Keep in mind that the firmware of the drive has to do it *exactly* right to make this work. I remember (shudder) the problems we had with an Archive 525Mb QIC streamer years ago. So, even if the driver does it right, I'd still advise people to check if their device does it also right. (People do test their backups do they? ;-) Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-scsi Thu Dec 11 13:55:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id NAA18983 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 13:55:02 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from colossus.dyn.ml.org (root@206-18-115-182.la.inreach.net [206.18.115.182]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA18961; Thu, 11 Dec 1997 13:54:55 -0800 (PST) (envelope-from dburr@POBoxes.com) Received: from control.colossus.dyn.ml.org (dburr@control.colossus.dyn.ml.org [192.160.60.1]) by colossus.dyn.ml.org (8.8.7/8.8.7) with SMTP id NAA06590; Thu, 11 Dec 1997 13:38:38 -0800 (PST) (envelope-from dburr@POBoxes.com) Message-ID: X-Mailer: XFMail 1.1 [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 In-Reply-To: <348F72F6.6B37@jump.net> Date: Thu, 11 Dec 1997 13:37:00 -0800 (PST) Organization: Starfleet Command From: Donald Burr To: Allan Alford Subject: Re: Wangtek 51000HT 1/4" SCSI-2 QIC 1000 Cc: freebsd-scsi@freebsd.org, freebsd-hardware@freebsd.org Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- My secret spy satellite informs me that on 11-Dec-97, Allan Alford wrote: >Also, Joerg, since you seem to know the particular device, I have one >last >question: > >The docs indicate that I can jump the 51000HT to be either SCSI-1 or >SCSI-2 >and yet the jumper maps show no such jumper. Currently, I'm SCSI 1. Do >you know how to set this? I have a Wangtek drive (5525ES), and it uses a software program (it runs under DOS *UGH*) to set this feature. I believe the 51000HT is similar. Check Tecmar's web site (they now own Wangtek) http://www.tecmar.com/ as this is where I got my copy of the program I mentioned. - --- Donald Burr - Ask me for my PGP key | PGP: Your WWW HomePage: http://DonaldBurr.base.org/ ICQ #1347455 | right to Address: P.O. Box 91212, Santa Barbara, CA 93190-1212 | 'Net privacy. Phone: (805) 957-9666 FAX: (800) 492-5954 | USE IT. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNJBdXPjpixuAwagxAQHc1AQAtktDb7YCh6R4geUex1VnFczn2/tTJxZp EgsYQlON7FkJqKnuVz+X9ysaevnMGwBZX1jVbTHVmOWxEMJSJMaWQqZY2Lhe1vSS J1oLB5mQH/hcki15XBVSswBUE8Zq1iAfStH1AQ1wQlPwVY+/Yc4M+eqo2KaWjeds qYaLNZxmMyM= =Rq2+ -----END PGP SIGNATURE----- From owner-freebsd-scsi Thu Dec 11 14:28:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA20565 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 14:28:02 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA20542 for ; Thu, 11 Dec 1997 14:27:53 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA27003 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Thu, 11 Dec 1997 23:27:27 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id WAA09859; Thu, 11 Dec 1997 22:08:10 +0100 (MET) From: Wilko Bulte Message-Id: <199712112108.WAA09859@yedi.iaf.nl> Subject: Re: RAID on FreeBSD To: tom@sdf.com (Tom) Date: Thu, 11 Dec 1997 22:08:09 +0100 (MET) Cc: walcaraz@indy3.gstone.com, freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Tom" at Dec 11, 97 10:45:43 am X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom wrote... > > On Thu, 11 Dec 1997, Walter .S. Alcaraz wrote: > > > I plan on purchasing FreeBSD 2.2.5 and installing it on a Pentium 200 or > > Pentium II 233 with 32 MB RAM. I want to run it as an NFS server with 32 GB > > storage and a 100-mbit Fast Ethernet card, running with a RAID Ultra-Wide SCSI > > controller. The setup I want to use is 9 4 GB Ultra-Wide SCSI drives, with a > > RAID controller doing RAID level 5. My question is, which RAID SCSI controller > > does FreeBSD support and what one works the best? > > The DPT PM334UW works well, but you need to install the driver yourself. > This card supports up to 64MB cache, and you can add additional channels > to it via a daughtercard (up to 3 UW channels in total). You will > probably want at least two channels. > > 9 drives in an uncomfortable number for RAID5. Probably better to go Why would 9 drives be uncomfartable? > with 10 drives instead, and make two 5 drive arrays. > > Tom _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-scsi Thu Dec 11 15:15:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA23208 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 15:15:11 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id PAA23199 for ; Thu, 11 Dec 1997 15:15:04 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xgHf3-0004ij-00; Thu, 11 Dec 1997 15:04:53 -0800 Date: Thu, 11 Dec 1997 15:04:51 -0800 (PST) From: Tom To: Wilko Bulte cc: walcaraz@indy3.gstone.com, freebsd-scsi@freebsd.org Subject: Re: RAID on FreeBSD In-Reply-To: <199712112108.WAA09859@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Wilko Bulte wrote: > > 9 drives in an uncomfortable number for RAID5. Probably better to go > > Why would 9 drives be uncomfartable? Well, if you are going to making one arrray of 9 drives, write performance will bad. If you are going to making 3 arrays of 3 drives each, you will end up with a lot of overhead. RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much bigger, just use RAID0 over multiple RAID5. 10 drives is a much nicer number. > > with 10 drives instead, and make two 5 drive arrays. > > > > Tom > _ ______________________________________________________________________ > | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko > |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' > ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ > > Tom From owner-freebsd-scsi Thu Dec 11 15:52:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25597 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 15:52:51 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25591 for ; Thu, 11 Dec 1997 15:52:47 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id AAA01956 for scsi@freebsd.org; Fri, 12 Dec 1997 00:52:41 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA13599; Fri, 12 Dec 1997 00:46:51 +0100 (MET) Message-ID: <19971212004650.09374@uriah.heep.sax.de> Date: Fri, 12 Dec 1997 00:46:50 +0100 From: J Wunsch To: scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712111641.IAA20249@math.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712111641.IAA20249@math.berkeley.edu>; from Dan Strick on Thu, Dec 11, 1997 at 08:41:03AM -0800 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As Dan Strick wrote: > In my opinion, short writes should not be allowed. The driver should > return an error in such circumstances. So how are you going to find out how much actual space there still has been in this case? Don't think of variable-length recording tapes in the first place, and assume the caller wanted to write 10 KB (aka. 20 blocks 512 bytes each). There were only 8 blocks free on the tape. How do you express this if you reject the complete write call, as opposed to writing 4 KB worth of data, and returning this to the caller? Btw., even if you want, you IMHO can't. You write them block by block to the tape, and get the EOM notification of the drive only after having written 4 KB of data. So, the data are actually there on the medium already, pretending to the caller they weren't would confuse the heck out of the volume-span logic of the corresponding program, when trying to read across the end of this volume. The only solution seems to be a `short write'. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Dec 11 15:54:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25741 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 15:54:27 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25731 for ; Thu, 11 Dec 1997 15:54:22 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id QAA07142; Thu, 11 Dec 1997 16:54:10 -0700 (MST) Message-Id: <199712112354.QAA07142@pluto.plutotech.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dan@math.berkeley.edu (Dan Strick) cc: scsi@freebsd.org Subject: Re: Questions about mt and SCSI subsystem In-reply-to: Your message of "Thu, 11 Dec 1997 08:08:16 PST." <199712111608.IAA19183@math.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 11 Dec 1997 16:52:21 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >> You favor this even if the media is specified to have a different EOD >> convention... perhaps even one that the drive writes on your behalf? > >Yes. Programs that read tapes should know as little as possible about >specific kinds of tape drives. In particular, they should not have to >know SCSI error codes. Note that not all SCSI tape drives support any >sort of end-of-recording recognition. Some just return a data error. So, the application must assume that two 0 length reads in a row means EOD even if the drive/media is perfectly capable of telling you this in a different manner? Of course, the program reading the tape can't assume that two 0 length reads in a row is EOD since it could very well be that a zero length file was written. If we don't want the program to have to do this, it seems as if the driver should interpret EOD as two filemarks in a row for the media types with this convention and only write two filemarks on these media types as well. >> > The convention that a raw tape driver return a single zero length > >I should have been more explicit. A tape driver should return a >single zero-length-read to indicate EOF. The next read should return >the first record of the next file on the tape (or nothing for another >EOF). This is the FreeBSD behavior. >Dan Strick >dan@math.berkeley.edu -- Justin From owner-freebsd-scsi Thu Dec 11 15:56:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA25953 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 15:56:55 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA25948 for ; Thu, 11 Dec 1997 15:56:50 -0800 (PST) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.8.8/8.8.8) with UUCP id AAA02218 for scsi@FreeBSD.ORG; Fri, 12 Dec 1997 00:56:39 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.8.8/8.8.5) id AAA13912; Fri, 12 Dec 1997 00:55:08 +0100 (MET) Message-ID: <19971212005508.47581@uriah.heep.sax.de> Date: Fri, 12 Dec 1997 00:55:08 +0100 From: J Wunsch To: scsi@FreeBSD.ORG Subject: Re: Questions about mt and SCSI subsystem Reply-To: Joerg Wunsch References: <199712100037.SAA25972@nospam.hiwaay.net> <199712100243.TAA18226@narnia.plutotech.com> <19971210093732.48185@uriah.heep.sax.de> <348F08D6.63DABEB6@whistle.com> <19971211005904.40551@uriah.heep.sax.de> <199712110327.UAA17646@narnia.plutotech.com> <19971211101003.17782@uriah.heep.sax.de> <199712111900.MAA00518@narnia.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.88 In-Reply-To: <199712111900.MAA00518@narnia.plutotech.com>; from Justin T. Gibbs on Thu, Dec 11, 1997 at 12:00:02PM -0700 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Justin T. Gibbs wrote: > It shouldn't return ENOSPC? This error code is documented in write.2. See Bruce's comments. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-scsi Thu Dec 11 16:02:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id QAA26284 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 16:02:10 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from gw1.tesys.com (root@gw1.tesys.com [207.5.58.2]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id QAA26278 for ; Thu, 11 Dec 1997 16:02:04 -0800 (PST) (envelope-from harry@tesys.com) Received: from harry (harry.tesys.com [207.5.58.17]) by gw1.tesys.com (8.7.4/8.7.3) with SMTP id QAA02167; Thu, 11 Dec 1997 16:02:08 -0800 (PST) Message-Id: <3.0.32.19971211155601.0092e580@gw1.tesys.com> X-Sender: harry@gw1.tesys.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 11 Dec 1997 15:56:02 -0800 To: Tom , Wilko Bulte From: Harry Aulakh Subject: Re: RAID on FreeBSD Cc: walcaraz@indy3.gstone.com, freebsd-scsi@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk At 03:04 PM 12/11/97 -0800, Tom wrote: > >On Thu, 11 Dec 1997, Wilko Bulte wrote: > >> > 9 drives in an uncomfortable number for RAID5. Probably better to go >> >> Why would 9 drives be uncomfartable? > > Well, if you are going to making one arrray of 9 drives, write >performance will bad. If you are going to making 3 arrays of 3 >drives each, you will end up with a lot of overhead. > > RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much >bigger, just use RAID0 over multiple RAID5. Please note that dual RAID support (dpt based) is not available under FreeBSD(there are few other OS's which do support it), as per my information.. Can someone verify that.. > > 10 drives is a much nicer number. > >> > with 10 drives instead, and make two 5 drive arrays. >> > Harry Aulakh Sr. Engineer Telenet System Solution Inc. 2480 kruse drive San Jose Ca-95131 Phone 408-383-0334 ext 111 fax 408-383-0335 Web www.tesys.com From owner-freebsd-scsi Thu Dec 11 18:18:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id SAA05681 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 18:18:03 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from rif.hoosierlink.net (rif.hoosierlink.net [208.154.69.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id SAA05665 for ; Thu, 11 Dec 1997 18:17:56 -0800 (PST) (envelope-from rif@rif.hoosierlink.net) Received: from localhost (rif@localhost) by rif.hoosierlink.net (8.8.8/8.8.6) with SMTP id VAA00760 for ; Thu, 11 Dec 1997 21:17:42 -0500 (EST) Date: Thu, 11 Dec 1997 21:17:42 -0500 (EST) From: Jim Riffle To: freebsd-scsi@freebsd.org Subject: possiable quirk with CTT8000-S Tape Drive Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have been attempting to get Amanda working with a CTT8000-Scsi tape drive, and may have stumbled on a quirk, or perhaps just a bug with Amanda. I have the following SCSI devices in my box. aic0 at 0x340-0x35f irq 9 on isa (aic0:0:0): "CONNER CTT8000-S 1.17" type 1 removable SCSI 2 st0(aic0:0:0): Sequential-Access density code 0x45, drive empty (aic0:2:0): "HP HP35470A T503" type 1 removable SCSI 2 st1(aic0:2:0): Sequential-Access density code 0x13, variable blocks, write-enabled Running amanda gives one of these 2 errors. st0(aic0:0:0): ILLEGAL REQUEST asc:80,81 Vendor Specific ASC st0(aic0:0:0): BLANK CHECK req sz: 32768 (decimal) asc:0,5 End-of-data detected If I run amanda on st1 (The HP tape), It works okay, so it appears to just be the Conner which has the trouble. If I run a simple "dump" command, on sd0, it works okay, which may mean this is a bug with Amanda instead.. I compiled SCSIDEBUG into my kernel, and get the following output with a debug level of 7, while running amanda. At the end there, I set the debug level back to 0, so there is extra stuff at the end. If anyone had any thoughts of things for me to try, I would apprecaite it greatly. st0(aic0:0:0): stclose: Closing device st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x20)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0xe0)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): Open complete st0(aic0:0:0): stopen: dev=0xe01 (unit 0) result 0 st0(aic0:0:0): [ioctl: op=0x5 count=0xefbfd7e4] st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x20)sc_link(0xf093ca80)retr(0x4)timo(0x493e0)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): ststrategy st0(aic0:0:0): 32768 bytes @ blk0 st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x420)sc_link(0xf093ca80)retr(0x0)timo(0x186a0)cmd(0xf093ca58)len(0x6)data(0xf46af7e4)len(0x8000)res(0x0)err(0x0)bp(0xf2d0dff4)st0(aic0:0:0): command: 8,0,0,80,0,0-[32768 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 8,0,0,80,0,0-[32768 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ st0(aic0:0:0): sc_err1,err = 0x1 code70 valid1 seg0 key8 ili0 eom0 fmark0 info: 0 0 80 0 followed by 10 extra bytes extra: 0 0 0 0 0 0 0 0 0 0 st0(aic0:0:0): calling private err_handler() st0(aic0:0:0): private err_handler() returned -1 st0(aic0:0:0): BLANK CHECK req sz: 32768 (decimal) asc:0,5 End-of-data detected st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): stclose: Closing device st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf093ca00): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf093ca58)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): stopen: dev=0x20000e00 (unit 0) result 0 st0(aic0:0:0): scsi_do_ioctl(0x80045102) st0(aic0:0:0): debug set to 0 st0(aic0:0:0): BLANK CHECK req sz: 32768 (decimal) asc:0,5 End-of-data detected Thanks, Jim --- Jim Riffle rif@hoosierlink.net HoosierLink & KC Online Network/Systems Administrator http://rif.kconline.com/ From owner-freebsd-scsi Thu Dec 11 19:33:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id TAA10583 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 19:33:56 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id TAA10576 for ; Thu, 11 Dec 1997 19:33:53 -0800 (PST) (envelope-from gibbs@plutotech.com) Received: from narnia.plutotech.com (narnia.plutotech.com [206.168.67.130]) by pluto.plutotech.com (8.8.7/8.8.5) with ESMTP id UAA27134 for ; Thu, 11 Dec 1997 20:33:51 -0700 (MST) Message-Id: <199712120333.UAA27134@pluto.plutotech.com> To: scsi@FreeBSD.org Subject: CAM Update. Date: Thu, 11 Dec 1997 20:32:02 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk I've uploaded a set of "incremental" diffs that will update a system running the 971209 snapshot to 971211. If you happen to be testing/using CAM, please drop me a line so I can find out what peripherals and adapters you have. For those of you using CAM on an SMP system, you might notice a few timeouts at boot time. It seems that in some systems the clock is running fast causing "bogus" timeouts. The system should recover from these timeouts and the boot proceed normally. Please let me know if that isn't the case for you. The 971211 snapshot includes the following changes: Tape Driver: The driver did not properly set the B_ERROR buffer flag when handling a defered EOF condition. This meant that the client would not see the residual. The driver now returns ENOSPC on writes that hit EOM. CDROM Driver: Correct a stupid logic bug that snuck in just before the last snapshot. This prevented CDROMs from being mounted. Aic7xxx Driver: Correct a bug that caused the driver to never renegotiate sync with wide targets after an automatic request sense. Needless to say, this killed performance. Don't use AAP to deal with the KERNEL_QINPOS scratch ram variable. There are occasions where the AAP write fails and the sequencer doesn't see a new entry in the input queue. Deal with "immediate resets" in the error recovery code correctly. These used to leave the controller queue in the frozen state so that no further I/O occured. XPT Layer: We now probe all device in parallel. This greatly increases the probe stage. The code already performed all device attachments in parallel. Snoop the device control page on devices that say they can perform tagged queuing. This allows us to read the DQUE flag indicating that tagged queuing is disabled on this target and avoid attempting any tagged I/O. Use cam_periph_error during device probes. In the past, the probe code bailed out on most errors. Fix a race condition that might allow a transaction to slip after a device queue or sim queue was placed into the frozen state. iostat: iostat will now report statistics for all CAM devices. It is far from it's final state though. Suggestions to ken@plutotech.com To apply the patches: cd /usr/src zcat cam-971211.incremental.diffs.gz | patch -p0 The patch may be obtain from: ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971211.incremental.diffs.gz or ftp://ftp.kdm.org/pub/FreeBSD/cam/cam-971211.incremental.diffs.gz -- Justin From owner-freebsd-scsi Thu Dec 11 20:51:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id UAA16922 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 20:51:12 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from rif.hoosierlink.net (rif.hoosierlink.net [208.154.69.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id UAA16909 for ; Thu, 11 Dec 1997 20:51:05 -0800 (PST) (envelope-from rif@rif.hoosierlink.net) Received: from localhost (rif@localhost) by rif.hoosierlink.net (8.8.8/8.8.6) with SMTP id XAA02204 for ; Thu, 11 Dec 1997 23:50:56 -0500 (EST) Date: Thu, 11 Dec 1997 23:50:56 -0500 (EST) From: Jim Riffle To: freebsd-scsi@freebsd.org Subject: Re: possiable quirk with CTT8000-S Tape Drive In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Jim Riffle wrote: Whoops! During my testing of this problem, I erased one of my tapes, taking off the label. So, the results I sent it this message were a result of that. I relabeled the tape, and here is what I get with amanda configured properly. I thought this data would be much more useful. st0(aic0:0:0): ILLEGAL REQUEST asc:80,81 Vendor Specific ASC That is the primary error. Below is with debug level 7. Sorry for the length of the output, I wasn't sure if all the info would be needed or not. st0(aic0:0:0): stclose: Closing device st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x20)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0xe0)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): Open complete st0(aic0:0:0): stopen: dev=0xe01 (unit 0) result 0 st0(aic0:0:0): [ioctl: op=0x5 count=0xefbfd7e4] st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x20)sc_link(0xf093ca80)retr(0x4)timo(0x493e0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): ststrategy st0(aic0:0:0): 32768 bytes @ blk0 st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x420)sc_link(0xf093ca80)retr(0x0)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0xf46af7e4)len(0x8000)res(0x0)err(0x0)bp(0xf2d0dff4)st0(aic0:0:0): command: 8,0,0,80,0,0-[32768 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 8,0,0,80,0,0-[32768 bytes] ------------------------------ 000: 41 4d 41 4e 44 41 3a 20 54 41 50 45 53 54 41 52 016: 54 20 44 41 54 45 20 58 20 54 41 50 45 20 41 6d 032: 61 6e 64 61 32 0a 0c 0a 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): stclose: Closing device st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x20)sc_link(0xf093ca80)retr(0x2)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 0,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0xe0)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,1,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): Open complete st0(aic0:0:0): stopen: dev=0xe01 (unit 0) result 0 st0(aic0:0:0): [ioctl: op=0x5 count=0x7b83] st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x20)sc_link(0xf093ca80)retr(0x0)timo(0x186a0)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 10,0,0,0,1,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 10,0,0,0,1,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x1 code70 valid1 seg0 key5 ili0 eom0 fmark0 info: 0 0 0 1 followed by 10 extra bytes extra: 0 0 0 0 0 0 0 0 0 0 st0(aic0:0:0): calling private err_handler() st0(aic0:0:0): private err_handler() returned -1 st0(aic0:0:0): ILLEGAL REQUEST asc:80,81 Vendor Specific ASC st0(aic0:0:0): scsi_interpret_sense (no bp) returned 22 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart st0(aic0:0:0): stclose: Closing device st0(aic0:0:0): scsi_cmd st0(aic0:0:0): get_xs st0(aic0:0:0): returning xs(0xf0e7d000): flg(0x60)sc_link(0xf093ca80)retr(0x2)timo(0x1388)cmd(0xf0e7d058)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): scsi_done st0(aic0:0:0): command: 1e,0,0,0,0,0-[0 bytes] st0(aic0:0:0): back in cmd() st0(aic0:0:0): sc_err1,err = 0x0 st0(aic0:0:0): free_xs st0(aic0:0:0): calling private start() st0(aic0:0:0): ststart > I have been attempting to get Amanda working with a CTT8000-Scsi tape > drive, and may have stumbled on a quirk, or perhaps just a bug with > Amanda. > > I have the following SCSI devices in my box. > > aic0 at 0x340-0x35f irq 9 on isa > (aic0:0:0): "CONNER CTT8000-S 1.17" type 1 removable SCSI 2 > st0(aic0:0:0): Sequential-Access density code 0x45, drive empty > (aic0:2:0): "HP HP35470A T503" type 1 removable SCSI 2 > st1(aic0:2:0): Sequential-Access density code 0x13, variable blocks, write-enabled > > Running amanda gives one of these 2 errors. > st0(aic0:0:0): ILLEGAL REQUEST asc:80,81 Vendor Specific ASC > st0(aic0:0:0): BLANK CHECK req sz: 32768 (decimal) asc:0,5 End-of-data detected > > If I run amanda on st1 (The HP tape), It works okay, so it appears to just > be the Conner which has the trouble. If I run a simple "dump" command, > on sd0, it works okay, which may mean this is a bug with Amanda instead.. > > I compiled SCSIDEBUG into my kernel, and get the following output with a > debug level of 7, while running amanda. At the end there, I set the debug > level back to 0, so there is extra stuff at the end. If anyone had any > thoughts of things for me to try, I would apprecaite it greatly. [snip] Jim From owner-freebsd-scsi Thu Dec 11 23:01:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA25341 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 23:01:21 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA25334 for ; Thu, 11 Dec 1997 23:01:18 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xgOwK-0004u1-00; Thu, 11 Dec 1997 22:51:12 -0800 Date: Thu, 11 Dec 1997 22:51:10 -0800 (PST) From: Tom To: Harry Aulakh cc: Wilko Bulte , walcaraz@indy3.gstone.com, freebsd-scsi@freebsd.org Subject: Re: RAID on FreeBSD In-Reply-To: <3.0.32.19971211155601.0092e580@gw1.tesys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 11 Dec 1997, Harry Aulakh wrote: > > RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much > >bigger, just use RAID0 over multiple RAID5. > > Please note that dual RAID support (dpt based) is not available under > FreeBSD(there are few other OS's which do support it), as per my > information.. Can someone verify that.. "dual RAID" is probably a misleading term. You can have multiple arrays with the FreeBSD dpt. I you want to stack arrays (ex. stripe multiple RAID5 arrays together), you can easily just use ccd, after all the hard part, RAID5 reliability, is being done by the controller. I believe the dpt support for stacked arrays, and arrays across is all handled in software within the driver anyhow. Tom From owner-freebsd-scsi Thu Dec 11 23:43:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA28663 for freebsd-scsi-outgoing; Thu, 11 Dec 1997 23:43:19 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id XAA28653 for ; Thu, 11 Dec 1997 23:43:16 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id XAA21046; Thu, 11 Dec 1997 23:32:02 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd021044; Thu Dec 11 23:32:01 1997 Date: Thu, 11 Dec 1997 23:29:25 -0800 (PST) From: Julian Elischer To: "Justin T. Gibbs" cc: scsi@FreeBSD.ORG Subject: Re: CAM Update. In-Reply-To: <199712120333.UAA27134@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Looks very nicely done from what I see. I'm living here in a non-scsi world so I can't help at all. (well, I have a scsi disk.. wow) have you looked at all at my DEVFS snapshot? it should be a snap to make this work on the CAM stuff. (but more documentation needs to be written) julian On Thu, 11 Dec 1997, Justin T. Gibbs wrote: > I've uploaded a set of "incremental" diffs that will update a system > running the 971209 snapshot to 971211. > > If you happen to be testing/using CAM, please drop me a line so I can > find out what peripherals and adapters you have. > > For those of you using CAM on an SMP system, you might notice a few > timeouts at boot time. It seems that in some systems the clock is > running fast causing "bogus" timeouts. The system should recover > from these timeouts and the boot proceed normally. Please let me > know if that isn't the case for you. > > The 971211 snapshot includes the following changes: > > Tape Driver: > The driver did not properly set the B_ERROR buffer flag when > handling a defered EOF condition. This meant that the client > would not see the residual. > > The driver now returns ENOSPC on writes that hit EOM. > > CDROM Driver: > Correct a stupid logic bug that snuck in just before the last > snapshot. This prevented CDROMs from being mounted. > > Aic7xxx Driver: > Correct a bug that caused the driver to never renegotiate sync > with wide targets after an automatic request sense. Needless > to say, this killed performance. > > Don't use AAP to deal with the KERNEL_QINPOS scratch ram variable. > There are occasions where the AAP write fails and the sequencer > doesn't see a new entry in the input queue. > > Deal with "immediate resets" in the error recovery code correctly. > These used to leave the controller queue in the frozen state so > that no further I/O occured. > > XPT Layer: > We now probe all device in parallel. This greatly increases the > probe stage. The code already performed all device attachments in > parallel. > > Snoop the device control page on devices that say they can perform > tagged queuing. This allows us to read the DQUE flag indicating that > tagged queuing is disabled on this target and avoid attempting any > tagged I/O. > > Use cam_periph_error during device probes. In the past, the probe > code bailed out on most errors. > > Fix a race condition that might allow a transaction to slip after > a device queue or sim queue was placed into the frozen state. > > iostat: > iostat will now report statistics for all CAM devices. It is far > from it's final state though. Suggestions to ken@plutotech.com > > To apply the patches: > > cd /usr/src > zcat cam-971211.incremental.diffs.gz | patch -p0 > > The patch may be obtain from: > > ftp://ftp.FreeBSD.org/pub/FreeBSD/cam/cam-971211.incremental.diffs.gz > or > ftp://ftp.kdm.org/pub/FreeBSD/cam/cam-971211.incremental.diffs.gz > > -- > Justin > From owner-freebsd-scsi Fri Dec 12 11:55:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA19474 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 11:55:07 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (root@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id LAA19465 for ; Fri, 12 Dec 1997 11:54:55 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA10734 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Fri, 12 Dec 1997 20:50:17 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id SAA01171; Fri, 12 Dec 1997 18:52:00 +0100 (MET) From: Wilko Bulte Message-Id: <199712121752.SAA01171@yedi.iaf.nl> Subject: Re: RAID on FreeBSD To: tom@sdf.com (Tom) Date: Fri, 12 Dec 1997 18:51:59 +0100 (MET) Cc: walcaraz@indy3.gstone.com, freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Tom" at Dec 11, 97 03:04:51 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom wrote... > On Thu, 11 Dec 1997, Wilko Bulte wrote: > > > > 9 drives in an uncomfortable number for RAID5. Probably better to go > > > > Why would 9 drives be uncomfartable? > > Well, if you are going to making one arrray of 9 drives, write > performance will bad. If you are going to making 3 arrays of 3 Why? Calculating the parity takes the same overhead in both cases. What you *don't* want to do is put too many drives of the same raidset on a single SCSI bus. Preferably you have only one drive of each set on each channel. This allows a channel to die completely without loosing your data. > drives each, you will end up with a lot of overhead. > > RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much > bigger, just use RAID0 over multiple RAID5. I don't agree. It *really* depends on the hardware you're using. E.g the company I work for (DEC) sells the HSZx0 range of controllers. This controller has (along with battery backup writeback cache) 6 SCSI device buses. The 'natural' number for that one is 6 drives. Generally my point is that you really have to take a very close look to your hardware setup. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ From owner-freebsd-scsi Fri Dec 12 14:05:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29257 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 14:05:49 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from misery.sdf.com (misery.sdf.com [204.244.210.193]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA29251 for ; Fri, 12 Dec 1997 14:05:44 -0800 (PST) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1) id 0xgd3G-0005mw-00; Fri, 12 Dec 1997 13:55:18 -0800 Date: Fri, 12 Dec 1997 13:55:16 -0800 (PST) From: Tom To: Wilko Bulte cc: walcaraz@indy3.gstone.com, freebsd-scsi@freebsd.org Subject: Re: RAID on FreeBSD In-Reply-To: <199712121752.SAA01171@yedi.iaf.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, Wilko Bulte wrote: > As Tom wrote... > > > On Thu, 11 Dec 1997, Wilko Bulte wrote: > > > > > > 9 drives in an uncomfortable number for RAID5. Probably better to go > > > > > > Why would 9 drives be uncomfartable? > > > > Well, if you are going to making one arrray of 9 drives, write > > performance will bad. If you are going to making 3 arrays of 3 > > Why? Calculating the parity takes the same overhead in both cases. To do a write, you will hae to read the data back from the other drives to calculate the parity. The more drives, the more data you have to read back, and more i/o you have to do to complete a write. You want to make a tradeoff between parity storage overhead and write performance. > What you *don't* want to do is put too many drives of the same raidset on > a single SCSI bus. Preferably you have only one drive of each set on > each channel. This allows a channel to die completely without loosing your > data. The question was about a 9 drive setup, that presumably going to be put into a single RAID5 array. How would you arrange 9 drives? > > drives each, you will end up with a lot of overhead. > > > > RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much > > bigger, just use RAID0 over multiple RAID5. > > I don't agree. It *really* depends on the hardware you're using. E.g > the company I work for (DEC) sells the HSZx0 range of controllers. > This controller has (along with battery backup writeback cache) 6 SCSI > device buses. The 'natural' number for that one is 6 drives. Yep, I knew you work DEC, and I knew you were probably baiting me. 5 is closer to 6, than to 9. So I guess you are closer to agreeing with me, than with a 9 drive RAID5 array. I guess the HSZx0 series, is a SCSI-to-SCSI system? Of course that imposes certain limitations as well. > Generally my point is that you really have to take a very close look > to your hardware setup. > > Wilko > _ ______________________________________________________________________ > | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko > |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' > ---------------- Support your local daemons: run [Free,Net]BSD Unix ------ > > Tom From owner-freebsd-scsi Fri Dec 12 14:08:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA29429 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 14:08:29 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from ns1.dpt.com (ns1.dpt.com [206.138.241.7]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA29424 for ; Fri, 12 Dec 1997 14:08:27 -0800 (PST) (envelope-from salyzyn_mark@dpt.com) Received: from bohica.bohica.dpt.com (bohica.dpt.com [198.242.63.84]) by ns1.dpt.com (8.7.4/8.7.3) with SMTP id SAA03437 for ; Fri, 12 Dec 1997 18:12:06 -0500 Received: by bohica.bohica.dpt.com [198.242.63.84] (NX5.67f2/NX3.0M) id AA20739; Fri, 12 Dec 97 17:09:09 -0500 Message-Id: <9712122209.AA20739@bohica.bohica.dpt.com> Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) Content-Type: text/plain; charset=us-ascii Received: by NeXT.Mailer (1.118.2) From: Mark Salyzyn Date: Fri, 12 Dec 97 17:09:08 -0500 To: freebsd-scsi@FreeBSD.ORG Subject: Re: RAID on FreeBSD Reply-To: salyzyn@dpt.com Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id OAA29425 Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk In article <3.0.32.19971211155601.0092e580@gw1.tesys.com>, you wrote: >At 03:04 PM 12/11/97 -0800, Tom wrote: >>On Thu, 11 Dec 1997, Wilko Bulte wrote: >>> > 9 drives in an uncomfortable number for RAID5. Probably better to go >>> Why would 9 drives be uncomfartable? >> Well, if you are going to making one arrray of 9 drives, write >>performance will bad. If you are going to making 3 arrays of 3 >>drives each, you will end up with a lot of overhead. >> RAID5 arrays of 5 drives is kinda of nice sweet spot. If you go much >>bigger, just use RAID0 over multiple RAID5. >Please note that dual RAID support (dpt based) is not available under >FreeBSD(there are few other OS's which do support it), as per my >information.. Can someone verify that.. Software RAID is not available for the current driver by Simon. However, we have supplied Simon sources to a RAID-0 subsystem that he may add to the driver in the future. There is nothing preventing an OS RAID-0 from being set up, the only disadvantages are that it is not integrated into the DPT management solutions and you can not boot off of a dual level RAID device utilizing the second level within an OS driver. Sincerely -- Mark Salyzyn From owner-freebsd-scsi Fri Dec 12 14:55:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA02972 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 14:55:47 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from mail.kcwc.com (h1.kcwc.com [206.139.252.2]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id OAA02967 for ; Fri, 12 Dec 1997 14:55:42 -0800 (PST) (envelope-from curt@kcwc.com) Received: by mail.kcwc.com (NX5.67c/NeXT-2.0-KCWC-1.0) id AA09122; Fri, 12 Dec 97 17:55:37 -0500 Date: Fri, 12 Dec 97 17:55:37 -0500 From: curt@kcwc.com (Curt Welch) Message-Id: <9712122255.AA09122@mail.kcwc.com> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: freebsd-scsi@FreeBSD.ORG Subject: Re: RAID on FreeBSD Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 12 Dec 1997, Wilko Bulte wrote: > > As Tom wrote... > > > Well, if you are going to making one arrray of 9 drives, write > > > performance will bad. If you are going to making 3 arrays of 3 > > > > Why? Calculating the parity takes the same overhead in both cases. > > To do a write, you will hae to read the data back from > the other drives to calculate the parity. The more > drives, the more data you have to read back, and more > i/o you have to do to complete a write. You want to make > a tradeoff between parity storage overhead and write > performance. No. To do a write, you read the parity block and the old data block. The new parity block is calculated by xoring these two blocks with the new data block (or something like that). You then write the new data block and the new parity block. It's always two reads and two writes no matter how many drives you have in the array. But, when a drive fails, then the controller must read blocks from all drives whenever you want to read or write a single block that was on the failed drive. So larger arrays can have serious performance problems when a drive fails - and if you need a certain level of performance to keep running this could be important. Curt Welch From owner-freebsd-scsi Fri Dec 12 22:44:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA00156 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 22:44:15 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from baloon.mimi.com (sjx-ca124-26.ix.netcom.com [207.223.162.154]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id WAA00148 for ; Fri, 12 Dec 1997 22:44:11 -0800 (PST) (envelope-from asami@sunrise.cs.berkeley.edu) Received: (from asami@localhost) by baloon.mimi.com (8.8.8/8.8.8) id WAA01273; Fri, 12 Dec 1997 22:44:01 -0800 (PST) (envelope-from asami) Date: Fri, 12 Dec 1997 22:44:01 -0800 (PST) Message-Id: <199712130644.WAA01273@baloon.mimi.com> To: curt@kcwc.com CC: freebsd-scsi@freebsd.org In-reply-to: <9712122255.AA09122@mail.kcwc.com> (curt@kcwc.com) Subject: Re: RAID on FreeBSD From: asami@cs.berkeley.edu (Satoshi Asami) Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk * From: curt@kcwc.com (Curt Welch) * No. To do a write, you read the parity block and the old * data block. The new parity block is calculated by xoring * these two blocks with the new data block (or something like * that). You then write the new data block and the new parity * block. It's always two reads and two writes no matter how * many drives you have in the array. It's not "always". If the write is larger than the whole stripe, you can just calculate parity in memory without reading anything. (This is basically what the various LFS + RAID5 combinations are trying to leverage from -- LFS -> large writes -> few parity reads.) Satoshi From owner-freebsd-scsi Fri Dec 12 23:36:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA02243 for freebsd-scsi-outgoing; Fri, 12 Dec 1997 23:36:35 -0800 (PST) (envelope-from owner-freebsd-scsi) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA02238 for ; Fri, 12 Dec 1997 23:36:32 -0800 (PST) (envelope-from wilko@yedi.iaf.nl) Received: by iafnl.es.iaf.nl with UUCP id AA04608 (5.67b/IDA-1.5 for freebsd-scsi@FreeBSD.ORG); Sat, 13 Dec 1997 08:36:47 +0100 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id AAA03706; Sat, 13 Dec 1997 00:12:38 +0100 (MET) From: Wilko Bulte Message-Id: <199712122312.AAA03706@yedi.iaf.nl> Subject: Re: RAID on FreeBSD To: tom@sdf.com (Tom) Date: Sat, 13 Dec 1997 00:12:38 +0100 (MET) Cc: walcaraz@indy3.gstone.com, freebsd-scsi@FreeBSD.ORG In-Reply-To: from "Tom" at Dec 12, 97 01:55:16 pm X-Organisation: Private FreeBSD site - Arnhem, The Netherlands X-Pgp-Info: PGP public key at 'finger wilko@freefall.freebsd.org' X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As Tom wrote... > > On Fri, 12 Dec 1997, Wilko Bulte wrote: > > > As Tom wrote... > > > > > On Thu, 11 Dec 1997, Wilko Bulte wrote: > > > > > > > > 9 drives in an uncomfortable number for RAID5. Probably better to go > > > > > > > > Why would 9 drives be uncomfartable? > > > > > > Well, if you are going to making one arrray of 9 drives, write > > > performance will bad. If you are going to making 3 arrays of 3 > > > > Why? Calculating the parity takes the same overhead in both cases. > > To do a write, you will hae to read the data back from the other drives > to calculate the parity. The more drives, the more data you have to read > back, and more i/o you have to do to complete a write. You want to make a > tradeoff between parity storage overhead and write performance. Not true. You don't have to read data from all the drives. You can satisfy a write by doing: 1. read datablock where the new data needs to go (target block) (drive A) 2. read corresponding parity block (drive B) 3. remove contribution to the parity block by exor-ing data from step 1 and 2. Keep the result. 4. create new parity by exor-ing the result of step 3 and the new data 5. write the parity block (to drive B) 6. write the new data (to drive A) What results is 2 reads from different spindles, and 2 writes to different spindles. Drive A and B can be parallelised pretty well with SCSI. The situation deteriorates if the write operation crosses chunk boundaries, you essentially have to repeat the recipe above. The trick with RAID5 is that you have to ensure you don't update data OR parity but you always have to do BOTH. If you have a crash of some sort when one of them has been written but the other has not you are really stuck. This is called the write hole. In software (host based) raid solutions this tends to be swept under the carpet. > > each channel. This allows a channel to die completely without loosing your > > data. > > The question was about a 9 drive setup, that presumably going to be put > into a single RAID5 array. How would you arrange 9 drives? Ideally on 9 channels ;-) > > I don't agree. It *really* depends on the hardware you're using. E.g > > the company I work for (DEC) sells the HSZx0 range of controllers. > > This controller has (along with battery backup writeback cache) 6 SCSI > > device buses. The 'natural' number for that one is 6 drives. > > Yep, I knew you work DEC, and I knew you were probably baiting me. ;-) > 5 is closer to 6, than to 9. So I guess you are closer to agreeing with > me, than with a 9 drive RAID5 array. > > I guess the HSZx0 series, is a SCSI-to-SCSI system? Of course that > imposes certain limitations as well. Yep, the later ones are Ultrawide differential SCSI to the host, and Ultra wide single ended to the disks. HSGx0 is FibreChannel host, to UW disks. There are of course limitations, for one more than 14 drives in one raid5 set are the max. number in a set. Wilko _ ______________________________________________________________________ | / o / / _ Bulte email: wilko @ yedi.iaf.nl http://www.tcja.nl/~wilko |/|/ / / /( (_) Arnhem, The Netherlands - Do, or do not. There is no 'try' ---------------- Support your local daemons: run [Free,Net]BSD Unix ------