From owner-freebsd-scsi Sun Sep 1 00:11:07 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA11999 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 00:11:07 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA11969 for ; Sun, 1 Sep 1996 00:11:01 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id PAA03615; Sun, 1 Sep 1996 15:10:36 +0800 (WST) Message-Id: <199609010710.PAA03615@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: gibbs@freefall.freebsd.org (Justin T. Gibbs), freebsd-scsi@freebsd.org Subject: Re: Putting the "experimental" SCSI system on a branch In-reply-to: Your message of "Sat, 31 Aug 1996 07:56:41 +0200." <199608310556.HAA07179@uriah.heep.sax.de> Date: Sun, 01 Sep 1996 15:10:36 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk J Wunsch wrote: > As Justin T. Gibbs wrote: > > > >Did you consider putting your changes on a CVS branch in > > >-current ? This would GREATLY reduce the amount of work > > >it takes me to have a development source tree .. > > > I hadn't thought much about this, but it would certainly allow > > others to contribute to this revamp. Peter, how hard would it > > be to set this up? > > I think all you need to do is to run easy-import on them, specify an > existing module name (sys_scsi), and perform a vendor-branch import. No, this is something completely different..... This will put it on the VENDOR branch for merging into HEAD. It will be generally inaccessable to the users. Any new files will appear on the HEAD revision. If you really want to do it this way, it's done by branching the kernel and putting your files in there. When people do an 'cvs update -r branchtag' they will no longer see changes in -current and only the new scsi system. Cheers, -Peter From owner-freebsd-scsi Sun Sep 1 00:33:17 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA12840 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 00:33:17 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA12831; Sun, 1 Sep 1996 00:33:15 -0700 (PDT) Message-Id: <199609010733.AAA12831@freefall.freebsd.org> To: Peter Wemm cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-scsi@freebsd.org Subject: Re: Putting the "experimental" SCSI system on a branch In-reply-to: Your message of "Sun, 01 Sep 1996 15:10:36 +0800." <199609010710.PAA03615@spinner.DIALix.COM> Date: Sun, 01 Sep 1996 00:33:15 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >No, this is something completely different..... This will put it on the >VENDOR branch for merging into HEAD. It will be generally inaccessable to >the users. Any new files will appear on the HEAD revision. Uh oh.... I wish you'd said something earlier. I just did as Joerg suggested. Ugh... >Cheers, >-Peter > > -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Sep 1 00:40:50 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id AAA13012 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 00:40:50 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id AAA13005 for ; Sun, 1 Sep 1996 00:40:41 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id PAA03722; Sun, 1 Sep 1996 15:39:42 +0800 (WST) Message-Id: <199609010739.PAA03722@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: "Justin T. Gibbs" cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-scsi@freebsd.org Subject: Re: Putting the "experimental" SCSI system on a branch In-reply-to: Your message of "Sun, 01 Sep 1996 00:33:15 MST." <199609010733.AAA12831@freefall.freebsd.org> Date: Sun, 01 Sep 1996 15:39:41 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Justin T. Gibbs" wrote: > >No, this is something completely different..... This will put it on the > >VENDOR branch for merging into HEAD. It will be generally inaccessable to > >the users. Any new files will appear on the HEAD revision. > > Uh oh.... I wish you'd said something earlier. I just did as Joerg > suggested. Ugh... Aargh! We've crossed over emails! :-/ Cheers, -Peter From owner-freebsd-scsi Sun Sep 1 08:21:16 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA00176 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 08:21:16 -0700 (PDT) Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id IAA00160 for ; Sun, 1 Sep 1996 08:21:11 -0700 (PDT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id RAA02827; Sun, 1 Sep 1996 17:21:05 +0200 Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id RAA01271; Sun, 1 Sep 1996 17:21:05 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.7.5/8.6.9) id RAA18148; Sun, 1 Sep 1996 17:06:21 +0200 (MET DST) From: J Wunsch Message-Id: <199609011506.RAA18148@uriah.heep.sax.de> Subject: Re: Putting the "experimental" SCSI system on a branch To: peter@spinner.DIALix.COM (Peter Wemm) Date: Sun, 1 Sep 1996 17:06:21 +0200 (MET DST) Cc: joerg_wunsch@uriah.heep.sax.de, gibbs@freefall.freebsd.org, freebsd-scsi@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199609010710.PAA03615@spinner.DIALix.COM> from Peter Wemm at "Sep 1, 96 03:10:36 pm" 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 X-Mailer: ELM [version 2.4ME+ PL17 (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 As Peter Wemm wrote: > > I think all you need to do is to run easy-import on them, specify an > > existing module name (sys_scsi), and perform a vendor-branch import. > > No, this is something completely different..... This will put it on the > VENDOR branch for merging into HEAD. It will be generally inaccessable to > the users. Any new files will appear on the HEAD revision. Well, i thought this is what Justin intented? The changes should finally go into HEAD, it's just that this needs to be deferred until everything is in a working state again. Now that it's already done, the new files appearing in HEAD don't matter much. It's simply that they aren't referred to by the Makefile yet. -- 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 Sep 1 09:20:43 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA02785 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 09:20:43 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA02774; Sun, 1 Sep 1996 09:20:41 -0700 (PDT) Message-Id: <199609011620.JAA02774@freefall.freebsd.org> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) cc: peter@spinner.DIALix.COM (Peter Wemm), freebsd-scsi@freebsd.org Subject: Re: Putting the "experimental" SCSI system on a branch In-reply-to: Your message of "Sun, 01 Sep 1996 17:06:21 +0200." <199609011506.RAA18148@uriah.heep.sax.de> Date: Sun, 01 Sep 1996 09:20:40 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >Well, i thought this is what Justin intented? The changes should >finally go into HEAD, it's just that this needs to be deferred until >everything is in a working state again. What I want is to put it someplace where other developers can also work on it. A vendor branch doesn't make the code accessible. >-- >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. ;-) -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Sun Sep 1 09:36:54 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA03209 for freebsd-scsi-outgoing; Sun, 1 Sep 1996 09:36:54 -0700 (PDT) Received: from spinner.DIALix.COM (spinner.DIALix.COM [192.203.228.67]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA03198 for ; Sun, 1 Sep 1996 09:36:44 -0700 (PDT) Received: from spinner.DIALix.COM (localhost.DIALix.oz.au [127.0.0.1]) by spinner.DIALix.COM (8.7.5/8.7.3) with ESMTP id AAA07249; Mon, 2 Sep 1996 00:35:38 +0800 (WST) Message-Id: <199609011635.AAA07249@spinner.DIALix.COM> X-Mailer: exmh version 1.6.7 5/3/96 To: "Justin T. Gibbs" cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-scsi@freebsd.org Subject: Re: Putting the "experimental" SCSI system on a branch In-reply-to: Your message of "Sun, 01 Sep 1996 09:20:40 MST." <199609011620.JAA02774@freefall.freebsd.org> Date: Mon, 02 Sep 1996 00:35:38 +0800 From: Peter Wemm Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk "Justin T. Gibbs" wrote: > >Well, i thought this is what Justin intented? The changes should > >finally go into HEAD, it's just that this needs to be deferred until > >everything is in a working state again. > > What I want is to put it someplace where other developers can also > work on it. A vendor branch doesn't make the code accessible. and nobody could commit to it... The rcs deltas involved were rather unpleasant as well, as the delta stored in the file was relative to rev 1.1 of the file, not -current. Having the relative-to-current code on the vendor branch produces a large delta. It would be better to simply branch the files and commit the changes, if only it wasn't for the LITE2 branch hanging off the side via cvsup.. Cheers, -Peter From owner-freebsd-scsi Thu Sep 5 11:02:19 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id LAA06162 for freebsd-scsi-outgoing; Thu, 5 Sep 1996 11:02:19 -0700 (PDT) Received: from boris.clintondale.com (boris.clintondale.com [206.88.120.5]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id LAA06156 for ; Thu, 5 Sep 1996 11:02:16 -0700 (PDT) Received: from localhost (matt@localhost) by boris.clintondale.com (8.7.5/8.7.3) with SMTP id OAA00280 for ; Thu, 5 Sep 1996 14:02:13 -0400 (EDT) Date: Thu, 5 Sep 1996 14:02:12 -0400 (EDT) From: Matt Hamilton Reply-To: Matt Hamilton To: freebsd-scsi@freebsd.org Subject: SCSI bus resets with C1534A 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 Hi all, I have a HP C1534A tape drive hanging off an Adaptec 2940 SCSI card. The other devices on the bus are: 0: Micropolis 9440 (2GB) 1: Micropolis 9440 (2GB) 4: HP HP35470A T503 5: Sanyo CD-ROM drive I am running 2.1.5-RELEASE and whenever I access the tape, eg. mt -f /dev/rst0 erase the Tape drive starts working and then after a couple of minutes I get: Sep 5 12:41:58 boris /kernel: st0(ahc0:4:0): timed out in dataout phase, SCSISI GI == 0x0 Sep 5 12:41:58 boris /kernel: st0(ahc0:4:0): BUS DEVICE RESET message queued. Sep 5 12:41:58 boris /kernel: Bus Device Reset Message Sent Sep 5 12:41:58 boris /kernel: st0(ahc0:4:0): Bus Device Reset delivered. 1 SCBs aborted When using dump it is even worse, it resets all the SCSI devices! and I am forced to cycle power. I have tried increasing the timeout values in sys/scsi/scsi_base.c (as mentioned in a bug report a couple of weeks ago) but this has not helped. Does anyone know what the problem could be? If I can't resolv this then I am considering moving to 2.2-SNAP-960801. Are there any differences in the SCSI code? I am a bit reluctant to do this as it is a production machine and has to remain as atable as possible. TIA, Matt Matt Hamilton matt@clintondale.com From owner-freebsd-scsi Fri Sep 6 08:55:22 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id IAA03058 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 08:55:22 -0700 (PDT) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [204.137.194.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id IAA03035; Fri, 6 Sep 1996 08:55:15 -0700 (PDT) Received: (from gordon@localhost) by unicorn.uk1.vbc.net (8.7.3/8.7.3) id QAA00717; Fri, 6 Sep 1996 16:54:34 +0100 Date: Fri, 6 Sep 1996 16:54:34 +0100 (BST) From: Gordon Henderson X-Sender: gordon@unicorn To: questions@freebsd.org, scsi@freebsd.org Subject: CCD Setup woes ... (Kernel Panic) Message-ID: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I'm tring to get a CCD going as an experiment and it's causing the kernel to panic. The hardware is: ASUS P120 motherboard, 128MB RAM, crappy old Adaptec ISA card (aha driver) and 3 x Maxtor 2GB drives. (ISA video, no ether yet) I'm using the adaptec card until I get some decent buslogic PCI cards. (I've had LOTS of problems with Adaptec 2940 PCI cards!) Drive 0 is the root disk and has /, swap, /usr and /var. Drives 1 & 2 are setup identical, 64MB swap partition (b) and the rest empty (partition f) for the ccd. (I'm not using the swap partitions yet, but read that it was a bad thing the have the ccd partitions at the start of the disk) I built a kernel with the ccd driver present as it says in the man page, did a cd /dev ; sh MAKEDEV ccd0 with no problems. Then I did: ccdconfig -c -v ccd0 32 none /dev/sd1f /dev/sd2f which resulted in a kernel panic. The message is: vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! panic: vm_bounce_alloc followed by the usual syncing disks bit. The number in the b_bufsize() varies from crash to crash. Am I doing anything obviously wrong? Gordon From owner-freebsd-scsi Fri Sep 6 09:25:16 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05129 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 09:25:16 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05107; Fri, 6 Sep 1996 09:25:11 -0700 (PDT) Message-Id: <199609061625.JAA05107@freefall.freebsd.org> To: Gordon Henderson cc: questions@freebsd.org, scsi@freebsd.org Subject: Re: CCD Setup woes ... (Kernel Panic) In-reply-to: Your message of "Fri, 06 Sep 1996 16:54:34 BST." Date: Fri, 06 Sep 1996 09:25:11 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >I'm using the adaptec card until I get some decent buslogic PCI cards. >(I've had LOTS of problems with Adaptec 2940 PCI cards!) I'd be interested to know what kinds of problems you're having with 2940s. You've never reported any bugs that I know of. > ccdconfig -c -v ccd0 32 none /dev/sd1f /dev/sd2f > >which resulted in a kernel panic. The message is: > > vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! > panic: vm_bounce_alloc A stack trace would be helpfull in tracking this down. Put DDB in your kernel (options DDB) and use the 'trace' command when the panic occurs. >Gordon -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Sep 6 09:29:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA05945 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 09:29:57 -0700 (PDT) Received: from al.imforei.apana.org.au (root@al.imforei.apana.org.au [202.12.89.41]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA05867 for ; Fri, 6 Sep 1996 09:29:47 -0700 (PDT) Received: (from pjchilds@localhost) by al.imforei.apana.org.au (8.7.5/8.7.3) id BAA10484; Sat, 7 Sep 1996 01:59:30 +0930 (CST) Date: Sat, 7 Sep 1996 01:59:30 +0930 (CST) From: Peter Childs Message-Id: <199609061629.BAA10484@al.imforei.apana.org.au> To: gordon@drogon.net, freebsd-scsi@freebsd.org Subject: Re: CCD Setup woes ... (Kernel Panic) X-Newsreader: TIN [version 1.2 PL2] Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk : ccdconfig -c -v ccd0 32 none /dev/sd1f /dev/sd2f : which resulted in a kernel panic. The message is: : vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! : panic: vm_bounce_alloc Ok.. quick sanity check :) What version of FreeBSD are you using, and you don't have the disks already mounted somewhere do you? And you did have the pseudo-device ccd 2 or whatever in your kernel file.. Peter -- Peter Childs --- http://www.imforei.apana.org.au/~pjchilds Finger pjchilds@al.imforei.apana.org.au for public PGP key Drag me, drop me, treat me like an object! From owner-freebsd-scsi Fri Sep 6 09:44:11 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11034 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 09:44:11 -0700 (PDT) Received: from freefall.freebsd.org (localhost.cdrom.com [127.0.0.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA10983; Fri, 6 Sep 1996 09:44:04 -0700 (PDT) Message-Id: <199609061644.JAA10983@freefall.freebsd.org> To: current, scsi Subject: New SCSI code on the "SCSI" branch Date: Fri, 06 Sep 1996 09:44:04 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk As you may have seen from the commit mail last night, I placed all of my work so far on the SCSI system onto the "SCSI" branch to allow for controlled testing and to incourage other developers to help out in the effort (hint, hint, 8-). Below I've included the relavent portion of sys/scsi/README that lists what I've done. If you have the CVS tree, you can try/work-on this code by using the following cvs command: cd /usr/src/sys cvs update -P -d -r SCSI scsi dev/aic7xxx i386/scsi i386/isa/bt5xx-445.c \ i386/isa/aha1542.c i386/isa/aic6360.c i386/isa/ncr5380.c \ i386/isa/seagate.c i386/isa/ultra14f.c i386/isa/wd7000.c \ i386/eisa/aic7770.c i386/eisa/aha1742.c i386/eisa/bt74x.c \ pci/ncr.c pci/ncrreg.h conf/files Do NOT do this: cd /usr/src/sys cvs update -P -d -r SCSI -f While the above command appears to do what you want, it adds a sticky tag of "TSCSI" on every file in the tree even if that tag is not in its corresponding RCS file. CVS will complain bitterly if you try to do ceratin opertions with your tree like this (say a cvs status or commit). Here's the README: ------Thu Sep 5 23:27:18 PDT 1996----- gibbs@FreeBSD.org 1) Made a first pass over the data structures: There is still lots of work to be done on the current set of data structures. My main changes were to remove obsolete fields, separate adapter reated information into a separate "adapter_link", and to create the scsi_queue structure. 2) Renamed flags and data structure members to lessen the differences with Open/NetBSD: There are lots of gratuitous and some not so gratuitous differences between the two camps SCSI code. I hope to bring the code bases closer together over the next month so that we can easily share controller drivers. 3) Changed how transfers are queued, started, and completed: The original scsi system has had a long standing problem with how queued transactions are handled. The root of the problem comes from the policy of deferring the reservation of controller resources until way down in the controller scsi_cmd routine where we may not have a process context and thus cannot always sleep. With these patches, the scsi system relies almost entirely on queue management instead of sleeping to handle its resources. More specifically, I've introduced a new data structure, the scsi_queue, that relates devices that share common controller resources. A scsi_queue has "openings" as do the individual scsi_links. A scsi_link is on the scsi_queue's run queue only when it has spare openings and work to do. When running a scsi_queue, the scsi_links are handled in round-robin fashion with each link allowed to send a single transaction per round. Before a transaction is dequeued, controller resources are obtained through adapter->get_cdb and attached to the scsi_xfer structure. get_cdb and free_cdb are two entry points provided by the controller drivers that encapsulate controller resource management. They should never be called directly by the controller driver (the wd7000 driver is the only current exception to this rule). Transaction ordering is also maintained by locking the scsi_link off the run queue until the controller drivers completes queueing the command. This strategy should yield greater performance since a freed controller resource can start any scsi_link attached to that device instead of only attempting to start pending transactions on the device that just completed a transaction. The round-robin scheme also ensures resource fairness when devices with multiple openings compete for a small number of resources. The scheduling algorithm should be changed to support real-time priorities. The scsi_queue structure is an opaque type to the controller drivers to make this easier to accomplish. 4) Centralized error handling and "done" processing: The scsi_cmd entry point now returns void. The controller drivers now exclusively use scsi_done() along with a properly set scsi_xfer->error to report errors. This removes superflous code paths and duplicated code. 5) Commands are built directly in the scsi_xfer structure instead of on the stack: The original design forced each and every command structure to be copied into the scsi_xfer by the scsi_scsi_cmd routine. The scsi_xfer is now obtained up front and the command built directly into the scsi_xfer->cmd_store. The members of the scsi_xfer structure are filled in directly via an inline function, scsi_prepare_xs, instead of stuffing all of them on the stack to simply be assigned into the scsi_xfer by scsi_scsi_cmd. scsi_scsi_cmd has also been replaced by scsi_schedule_xs(). 6) Converted individual controller resource management to use the queue(3) macros. Many of the drivers performed complicated list manipulations that were simplified by using the queue macros. The generic scsi layer's queue managment is also queue(3) based. 7) Removed error detection and reporting from the xxstart routines: The goal here is to make the xxstart routines as small and efficient as possible. Error detection occurs in the strategy routine or in the sense handlers. If an error is detected that may affect queued transactions, the new driver entry point clean_queue() is called to synchronously remove any entries that would have been gradually drained by the start routines in the past. 8) Added the complete driver entry point: The complete entry point is called as the last operation on a scsi_xfer before it is freed. This is the place where device usage statistic hooks should be added. In NetBSD, they have overloaded the scsi_done routine by adding an additional argument to serve this purpose which I think is the wrong approach. Currently all disk type drivers have a complete routine using the old dk_* stat stuff. Eventually I'd like to bring in NetBSD's disk status code which is much cleaner and provides more information. 9) Removed the async driver entry point: This entry point has never been used. 10) Brough in Jason Thorpe's ch driver. I haven't added the quirk entries for the supported changers yet, but we should probably invert the meaning of our quirks (probe multiple luns by default) first. 11) Set the lun in the second byte of CDBs. This was brought up on the NetBSD lists and the lack of setting it is probably the main reason for our code probing multiple luns on so many devices. The SCSI-II spec allows for the lun to be set although it is "optional". 12) Removed the need for a static scsi_link prototype and dummy scsi_device entry in each controller driver. 13) Added tagged queueing support to the generic SCSI code and modified the aic7xxx driver to use it. We now honor the B_ORDERED buffer flag and convert sync writes to async/ordered writes if the target device does tagged queueing. 14) Added proper, timeout based, retries for the XS_BUSY case. We don't retry until either the timeout expires or the target successfully completes a command. This should also be done for the QUEUE FULL condition, but that is NYI. 15) Brought in NetBSD's scsi_message.h file and converted the generic scsi scsi layer and the aic7xxx driver to use its constants instead of home grown ones. -- Justin T. Gibbs =========================================== FreeBSD: Turning PCs into workstations =========================================== From owner-freebsd-scsi Fri Sep 6 09:45:54 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id JAA11708 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 09:45:54 -0700 (PDT) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [204.137.194.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id JAA11680 for ; Fri, 6 Sep 1996 09:45:50 -0700 (PDT) Received: (from gordon@localhost) by unicorn.uk1.vbc.net (8.7.3/8.7.3) id RAA00982; Fri, 6 Sep 1996 17:45:26 +0100 Date: Fri, 6 Sep 1996 17:45:25 +0100 (BST) From: Gordon Henderson X-Sender: gordon@unicorn To: Peter Childs cc: freebsd-scsi@freebsd.org Subject: Re: CCD Setup woes ... (Kernel Panic) In-Reply-To: <199609061629.BAA10484@al.imforei.apana.org.au> Message-ID: Distribution: world Organization: Home for lost Drogons MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 7 Sep 1996, Peter Childs wrote: > : ccdconfig -c -v ccd0 32 none /dev/sd1f /dev/sd2f > > : which resulted in a kernel panic. The message is: > > : vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! > : panic: vm_bounce_alloc > > Ok.. quick sanity check :) What version of FreeBSD are you > using, and you don't have the disks already mounted somewhere > do you? 2.1.5R. None of them were mounted. (they do/did have valid file systems on them because I did mount them at one stage to test them but I made sure they were unmounted when I was trying the ccd stuff. (besides, the machine had crashed & rebooted several times anyway and they are not mentioned in the fstab file) > And you did have the pseudo-device ccd 2 or whatever in your > kernel file.. Yes. (4) The kernel boots & recognises it. I did have one minor problem at one time because I have an /etc/ccd.conf file and I didn't realise that there was a ccdconfig -C in /etc/rc ... machine boot, machine panic, etc... Good job I'd left a generic kernel there... Gordon From owner-freebsd-scsi Fri Sep 6 10:08:22 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA13359 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 10:08:22 -0700 (PDT) Received: from unicorn.uk1.vbc.net (unicorn.uk1.vbc.net [204.137.194.11]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA13347 for ; Fri, 6 Sep 1996 10:08:19 -0700 (PDT) Received: (from gordon@localhost) by unicorn.uk1.vbc.net (8.7.3/8.7.3) id SAA01065; Fri, 6 Sep 1996 18:08:15 +0100 Date: Fri, 6 Sep 1996 18:08:15 +0100 (BST) From: Gordon Henderson X-Sender: gordon@unicorn To: "Justin T. Gibbs" cc: freebsd-scsi@freebsd.org Subject: Re: CCD Setup woes ... (Kernel Panic) In-Reply-To: <199609061625.JAA05107@freefall.freebsd.org> Message-ID: Distribution: world Organization: Home for lost Drogons 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, 6 Sep 1996, Justin T. Gibbs wrote: > > ccdconfig -c -v ccd0 32 none /dev/sd1f /dev/sd2f > > > >which resulted in a kernel panic. The message is: > > > > vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! > > panic: vm_bounce_alloc > > A stack trace would be helpfull in tracking this down. Put DDB in your > kernel (options DDB) and use the 'trace' command when the panic occurs. I'm having to copy this over by hand, but it goes: _Debugger _panic _vm_bounce_alloc _sd_strategy _scsi_strategy _sdstrategy _spec_strategy _ccdstart _ccdstrategy _correct_readdisklabel _ccdgetdisklabel _ccdioctl _spec_ioctl _vm_ioctl _ioctl _syscall It's FreeBSD 2.1.5R... Gordon -- Gordon Henderson gordon@vbc.net VBCnet GB Ltd http://www.uk.vbc.net/ Bristol, England +44 117 929 1316 fax +44 117 927 2015 From owner-freebsd-scsi Fri Sep 6 20:52:01 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA29136 for freebsd-scsi-outgoing; Fri, 6 Sep 1996 20:52:01 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA29017; Fri, 6 Sep 1996 20:50:29 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.7.5/8.6.9) id WAA02660; Fri, 6 Sep 1996 22:50:07 -0500 (EST) From: "John S. Dyson" Message-Id: <199609070350.WAA02660@dyson.iquest.net> Subject: Re: CCD Setup woes ... (Kernel Panic) To: gordon@drogon.net (Gordon Henderson) Date: Fri, 6 Sep 1996 22:50:07 -0500 (EST) Cc: questions@freebsd.org, scsi@freebsd.org In-Reply-To: from "Gordon Henderson" at Sep 6, 96 04:54:34 pm Reply-To: dyson@freebsd.org X-Mailer: ELM [version 2.4 PL24 ME8] 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 > > I'm tring to get a CCD going as an experiment and it's causing the kernel > to panic. > Yep, there is a problem with CCD using the FreeBSD bounce scheme. Of course, it is only noticed on ISA systems. > > which resulted in a kernel panic. The message is: > > vm_bounce_alloc: b_bufsize(0x80) < b_count(0x200) !! > panic: vm_bounce_alloc > b_bufsize is not being setup correctly in ccd (I think). > > followed by the usual syncing disks bit. The number in the b_bufsize() > varies from crash to crash. > > Am I doing anything obviously wrong? > No. Hope the following works for you!!! If it does, let me know so that I can commit it. Try this patch to ccd relative to -current (the equiv patch might work for -stable), I haven't tested this though: Index: ccd.c =================================================================== RCS file: /local/home/ncvs/src/sys/dev/ccd/ccd.c,v retrieving revision 1.16 diff -C5 -r1.16 ccd.c *** ccd.c 1996/07/24 23:45:24 1.16 --- ccd.c 1996/09/07 03:46:27 *************** *** 909,918 **** --- 909,920 ---- else cbp->cb_buf.b_bcount = dbtob(cs->sc_ileave - cboff); if (cbp->cb_buf.b_bcount > bcount) cbp->cb_buf.b_bcount = bcount; + cbp->cb_buf.b_bufsize = cbp->cb_buf.b_bcount; + /* * context for ccdiodone */ cbp->cb_obp = bp; cbp->cb_unit = cs - ccd_softc; From owner-freebsd-scsi Sat Sep 7 14:46:41 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA14034 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 14:46:41 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA14022; Sat, 7 Sep 1996 14:46:36 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id RAA28226; Sat, 7 Sep 1996 17:46:15 -0400 Date: Sat, 7 Sep 1996 17:46:14 -0400 (EDT) From: Brian Tao To: Narvi cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays 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 Wed, 28 Aug 1996, Narvi wrote: > > Could you give back any views you have on it? I have my I on the CMDs > external cabinet with 4/6 slots (depends on the drive size). I'll echo > back when we have acquired one and tested it out... I'm looking at Raidion, CMD, Mylex and a local Toronto integrator called Dataplex. One thing in common is the impressive cost. ;-) A RAID controller and a RAID-ready cabinet that will hold 6 or so drives costs around C$5000 up here. I also prefer 19" rackmount and DC power versions, which will only add to the cost. My sales rep at Tenex Data has promised an eval Raidion, and Open Storage Solutions can probably do the same for a CMD unit. I haven't had a chance to find a Mylex reseller in town yet. With the amount of money that the company is about to spend on this stuff, I might be able to donate a few bills to the FreeBSD DPT driver effort too. :) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sat Sep 7 15:31:09 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA18710 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 15:31:09 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA18702; Sat, 7 Sep 1996 15:31:06 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id SAA02667; Sat, 7 Sep 1996 18:31:03 -0400 Date: Sat, 7 Sep 1996 18:31:03 -0400 (EDT) From: Brian Tao To: Ken Lam cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: <1.5.4.32.19960829002801.00913104@awod.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 Wed, 28 Aug 1996, Ken Lam wrote: > > I didn't get a chance to test it under FreeBSD. Fairly fast, but > other than the RAID 5 aspect, why not use CCD? Well, ccd is a start, and I may consider it more seriously if the costs of hardware RAID prove to be too high (we're looking at 5 or 6 6-drive units to start). ccd is free, but it doesn't give you hot-swappable drives, automatic data rebuild on a spare drive and a battery-powered write back cache. I'm going to stick with hardware RAID on the news servers, but ccd should do just fine on our main mail server. Raw capacity is what I'm aiming for there, not big TPS numbers or huge disk throughput. -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sat Sep 7 15:42:58 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA19237 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 15:42:58 -0700 (PDT) Received: from io.org (io.org [198.133.36.1]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA19229; Sat, 7 Sep 1996 15:42:55 -0700 (PDT) Received: from zap.io.org (taob@zap.io.org [198.133.36.81]) by io.org (8.6.12/8.6.12) with SMTP id SAA03612; Sat, 7 Sep 1996 18:41:35 -0400 Date: Sat, 7 Sep 1996 18:41:35 -0400 (EDT) From: Brian Tao To: Joe Greco cc: Ken Lam , freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org Subject: Re: Streamlogic RAIDION drive arrays In-Reply-To: <199608291420.JAA06736@brasil.moneng.mei.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, 29 Aug 1996, Joe Greco wrote: > > If it has write back cache, you have a reason to look at it :-) The fellow at Tenex didn't have the answer to most of my questions, but he took a list back to one of his engineers and he'll get back to me on Monday. ;-) > I've been considering trying something like a Mylex DAC960SI (?), > SCSI-to-SCSI RAID controller, simply for the cache you can stick on > it. The CMD Daytona RAIDarray looks like a winner in this arena. I'm interested in the version with their CRD-5300 integrated with a six-bay tower. It will take up to 64MB of battery-backed RAM, supports hot-swappable drives, supports command queueing and has redundant power supplies. You just have a single SCSI F/W cable plugged into the back. http://www.cmd.com/product/raid/daytona.htm After spending several hours early Saturday morning reconfiguring our NFS server because of a bad drive in a conventional external case with those annoying screw-on drive rails, I'm going to enjoy having a real cabinet to work with. :) -- Brian Tao (BT300, taob@io.org, taob@ican.net) Senior Systems and Network Administrator, Internet Canada Corp. "Though this be madness, yet there is method in't" From owner-freebsd-scsi Sat Sep 7 16:02:57 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA20191 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 16:02:57 -0700 (PDT) Received: from po1.glue.umd.edu (po1.glue.umd.edu [129.2.128.44]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA20160; Sat, 7 Sep 1996 16:02:23 -0700 (PDT) Received: from fiber.eng.umd.edu (fiber.eng.umd.edu [129.2.98.185]) by po1.glue.umd.edu (8.8.Beta.0/8.7.3) with ESMTP id TAA01665; Sat, 7 Sep 1996 19:02:19 -0400 (EDT) Received: from localhost (chuckr@localhost) by fiber.eng.umd.edu (8.7.5/8.7.3) with SMTP id TAA29592; Sat, 7 Sep 1996 19:02:18 -0400 (EDT) X-Authentication-Warning: fiber.eng.umd.edu: chuckr owned process doing -bs Date: Sat, 7 Sep 1996 19:02:18 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@fiber.eng.umd.edu To: Brian Tao cc: Ken Lam , FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays 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 Sat, 7 Sep 1996, Brian Tao wrote: > On Wed, 28 Aug 1996, Ken Lam wrote: > > > > I didn't get a chance to test it under FreeBSD. Fairly fast, but > > other than the RAID 5 aspect, why not use CCD? > > Well, ccd is a start, and I may consider it more seriously if the > costs of hardware RAID prove to be too high (we're looking at 5 or 6 > 6-drive units to start). ccd is free, but it doesn't give you > hot-swappable drives, automatic data rebuild on a spare drive > and a battery-powered write back cache. > > I'm going to stick with hardware RAID on the news servers, but ccd > should do just fine on our main mail server. Raw capacity is what I'm > aiming for there, not big TPS numbers or huge disk throughput. This seems somewhat odd to me. I thought you'd expend the additional cost of RAID where you really need reliability. If you lose news (assuming this doesn't happen very often) you just reload from another server, right? If you lose mail, it's gone, no backup at all. Raid (I understand) doesn't give you raw massive data, it gives you reliability at the cost of dollars and some lost capacity. CCD gives you the capacity completely, disk for disk, but doesn't allow the neat reliability features of a RAID box. If you're shooing for raw capacity, this doesn't seem to make sense. What am I missing? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and n3lxx, both FreeBSD (301) 220-2114 | version 2.2 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-scsi Sat Sep 7 16:47:02 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id QAA21750 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 16:47:02 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id QAA21745; Sat, 7 Sep 1996 16:46:59 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA02543; Sat, 7 Sep 1996 16:45:10 -0700 From: Terry Lambert Message-Id: <199609072345.QAA02543@phaeton.artisoft.com> Subject: Re: Streamlogic RAIDION drive arrays To: chuckr@glue.umd.edu (Chuck Robey) Date: Sat, 7 Sep 1996 16:45:10 -0700 (MST) Cc: taob@io.org, klam@awod.com, freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: from "Chuck Robey" at Sep 7, 96 07:02:18 pm X-Mailer: ELM [version 2.4 PL24] 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 > > I'm going to stick with hardware RAID on the news servers, but ccd > > should do just fine on our main mail server. Raw capacity is what I'm > > aiming for there, not big TPS numbers or huge disk throughput. > > This seems somewhat odd to me. I thought you'd expend the additional cost > of RAID where you really need reliability. If you lose news (assuming > this doesn't happen very often) you just reload from another server, > right? If you lose mail, it's gone, no backup at all. What if: 1) You sell commercial feed services, so the news has to be reliable? If you loase your feed data, so does everyone down stream from you. 2) You sell posting services (as an ISP)? If your crash occurs before the feed distribution, but after an article has been posted, your customer's article is lost. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. From owner-freebsd-scsi Sat Sep 7 20:16:36 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA14457 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 20:16:36 -0700 (PDT) Received: from sasami.jurai.net (root@sasami.jurai.net [206.151.208.162]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA14444; Sat, 7 Sep 1996 20:16:33 -0700 (PDT) Received: from localhost (winter@localhost) by sasami.jurai.net (8.7.5/8.7.3) with SMTP id WAA25717; Sat, 7 Sep 1996 22:16:56 -0500 (CDT) Date: Sat, 7 Sep 1996 22:16:56 -0500 (CDT) From: "Matthew N. Dodd" To: Brian Tao cc: FREEBSD-HACKERS-L , FREEBSD-SCSI-L Subject: Re: Streamlogic RAIDION drive arrays 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 Sat, 7 Sep 1996, Brian Tao wrote: > I'm looking at Raidion, CMD, Mylex and a local Toronto integrator > called Dataplex. One thing in common is the impressive cost. ;-) A Check out BoxHill. They have some nifty stuff. They are a CMD integrator. http://www.boxhill.com/ | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-scsi Sat Sep 7 22:27:13 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA24971 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 22:27:13 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA24944; Sat, 7 Sep 1996 22:27:05 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id AAA17753; Sun, 8 Sep 1996 00:23:08 -0500 From: Joe Greco Message-Id: <199609080523.AAA17753@brasil.moneng.mei.com> Subject: Re: Streamlogic RAIDION drive arrays To: terry@lambert.org (Terry Lambert) Date: Sun, 8 Sep 1996 00:23:08 -0500 (CDT) Cc: chuckr@glue.umd.edu, taob@io.org, klam@awod.com, freebsd-hackers@FreeBSD.org, freebsd-scsi@FreeBSD.org In-Reply-To: <199609072345.QAA02543@phaeton.artisoft.com> from "Terry Lambert" at Sep 7, 96 04:45:10 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > What if: > > 1) You sell commercial feed services, so the news has to be reliable? > If you loase your feed data, so does everyone down stream from > you. You should still be able to recover. In case of catastrophic failure, I generally try to rebuild back past the point at which my drive crashed anyways. Having to absorb the penalty for RAID operations may reduce your spool's throughput anyways.. > 2) You sell posting services (as an ISP)? If your crash occurs > before the feed distribution, but after an article has been > posted, your customer's article is lost. That would be a matter of incompetence. If you are not doing real time outbound feeds in this day and age, you do not belong playing the news game. I can measure propagation time for locally posted articles from any of the news servers that I run to any of the Top 5 news servers in terms of seconds.. and count on one hand. :-) (I may be an example of an unusually well connected site, but the point is, I move the articles and I do so _fast_). ... JG From owner-freebsd-scsi Sat Sep 7 22:27:15 1996 Return-Path: owner-freebsd-scsi Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id WAA24984 for freebsd-scsi-outgoing; Sat, 7 Sep 1996 22:27:15 -0700 (PDT) Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA24966; Sat, 7 Sep 1996 22:27:11 -0700 (PDT) Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id AAA17764; Sun, 8 Sep 1996 00:25:37 -0500 From: Joe Greco Message-Id: <199609080525.AAA17764@brasil.moneng.mei.com> Subject: Re: Streamlogic RAIDION drive arrays To: taob@io.org (Brian Tao) Date: Sun, 8 Sep 1996 00:25:36 -0500 (CDT) Cc: klam@awod.com, freebsd-hackers@freebsd.org, freebsd-scsi@freebsd.org In-Reply-To: from "Brian Tao" at Sep 7, 96 06:31:03 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > I'm going to stick with hardware RAID on the news servers, but ccd > should do just fine on our main mail server. Raw capacity is what I'm > aiming for there, not big TPS numbers or huge disk throughput. Question: Wouldn't you want RAID on your mail server, _instead?_ ... For news, the RAID buys you a write back cache and nothing else. For mail, it buys you reliability with customer data that is not easily replaced like news is. Just curious. ... JG