From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 21 11:02:50 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B354816A41F for ; Mon, 21 Nov 2005 11:02:50 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 590EB43D5D for ; Mon, 21 Nov 2005 11:02:42 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jALB2fBJ090187 for ; Mon, 21 Nov 2005 11:02:41 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jALB2fIq090181 for freebsd-scsi@freebsd.org; Mon, 21 Nov 2005 11:02:41 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 21 Nov 2005 11:02:41 GMT Message-Id: <200511211102.jALB2fIq090181@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 11:02:50 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/05/03] kern/27059 scsi [sym] SCSI subsystem hangs under heavy lo o [2001/06/29] kern/28508 scsi problems with backup to Tandberg SLR40 st o [2002/06/17] kern/39388 scsi ncr/sym drivers fail with 53c810 and more o [2002/07/22] kern/40895 scsi wierd kernel / device driver bug o [2003/05/24] kern/52638 scsi [panic] SCSI U320 on SMP server won't run s [2003/09/30] kern/57398 scsi [mly] Current fails to install on mly(4) o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with o [2003/12/27] kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C81 s [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/12/02] kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5 o [2005/06/04] kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceP 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/12/06] kern/23314 scsi aic driver fails to detect Adaptec 1520B o [2001/08/15] kern/29727 scsi [amr] [patch] amr_enquiry3 structure in a o [2002/02/23] kern/35234 scsi World access to /dev/pass? (for scanner) o [2002/06/02] kern/38828 scsi [feature request] DPT PM2012B/90 doesn't o [2002/10/29] kern/44587 scsi dev/dpt/dpt.h is missing defines required o [2003/10/01] kern/57469 scsi [scsi] [patch] Quirk for Conner CP3500 o [2005/01/12] kern/76178 scsi [ahd] Problem with ahd and large SCSI Rai 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 21 20:50:33 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E0716A41F for ; Mon, 21 Nov 2005 20:50:33 +0000 (GMT) (envelope-from BJones@business.otago.ac.nz) Received: from mailhub1.otago.ac.nz (mailhub1.otago.ac.nz [139.80.64.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BA6143D80 for ; Mon, 21 Nov 2005 20:50:22 +0000 (GMT) (envelope-from BJones@business.otago.ac.nz) Received: from SOBMAIL1.commerce.otago.ac.nz (sbadex02.commerce.otago.ac.nz [139.80.81.53]) by mailhub1.otago.ac.nz (8.12.11/8.12.11) with ESMTP id jALKoJwL007453 for ; Tue, 22 Nov 2005 09:50:20 +1300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Nov 2005 09:50:19 +1300 Message-ID: <50FA41D5C67C3D48AB08A338C9B7A0196508B9@SOBMAIL1.commerce.otago.ac.nz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: iSCSI, where to look? Thread-Index: AcXu3S8Pq4DDYLTMQIaSjvqHHOpQqg== From: "Brent Jones" To: Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: iSCSI, where to look? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 20:50:33 -0000 Hi there - I'm about to deploy a server which I'm hoping can be FreeBSD based (long time BSD user since the mid 80s...) The need for iSCSI connectivity to our SAN in the medium term future could however dictate that I go with a (gulp) Linux installation instead. Where can I find more information on the state of iSCSI and FreeBSD? I'm quite willing to work as a tester. If iSCSI looks like it will be there in the next 12 months with FreeBSD, I can stick with it and not go with Linux (I don't want to have to learn/support something new...). I found a reference to FreeBSD and iSCSI on a web archive, so a pointer to a FreeBSD/iSCSI mailing list or equivalent would be great. Cheers, Brent -- J. Brent Jones, Manager, Technology Services University of Otago, School of Business Dunedin NEW ZEALAND=20 Phone: +64 3 479 8042 http://www.otago.ac.nz/business From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 21 23:22:38 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73B7216A41F for ; Mon, 21 Nov 2005 23:22:38 +0000 (GMT) (envelope-from aelmore@interwoven.com) Received: from smtp01corp.interwoven.com (smtp02corp.interwoven.com [65.161.4.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A11643D49 for ; Mon, 21 Nov 2005 23:22:38 +0000 (GMT) (envelope-from aelmore@interwoven.com) Received: from exbesv02.Interwoven.com (localhost [127.0.0.1]) by smtp01corp.interwoven.com (8.12.10/8.12.10) with ESMTP id jALNMUeI015928; Mon, 21 Nov 2005 15:22:30 -0800 (PST) Received: from exbesv01.Interwoven.com ([10.192.4.77]) by exbesv02.Interwoven.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:22:30 -0800 Received: from relax.amer.interwoven.com ([10.192.11.188]) by exbesv01.Interwoven.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Nov 2005 15:22:30 -0800 Received: from relax.amer.interwoven.com (localhost [127.0.0.1]) by relax.amer.interwoven.com (8.13.4/8.13.4) with ESMTP id jALNMTZ6086705; Mon, 21 Nov 2005 15:22:29 -0800 (PST) (envelope-from aelmore@relax.amer.interwoven.com) Received: (from aelmore@localhost) by relax.amer.interwoven.com (8.13.4/8.13.4/Submit) id jALNMT3f086704; Mon, 21 Nov 2005 15:22:29 -0800 (PST) (envelope-from aelmore) Date: Mon, 21 Nov 2005 15:22:28 -0800 From: Andrew Elmore To: Brent Jones Message-ID: <20051121232228.GC85750@interwoven.com> References: <50FA41D5C67C3D48AB08A338C9B7A0196508B9@SOBMAIL1.commerce.otago.ac.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50FA41D5C67C3D48AB08A338C9B7A0196508B9@SOBMAIL1.commerce.otago.ac.nz> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 21 Nov 2005 23:22:30.0156 (UTC) FILETIME=[71604CC0:01C5EEF2] Cc: freebsd-scsi@freebsd.org Subject: Re: iSCSI, where to look? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2005 23:22:38 -0000 On Tue, Nov 22, 2005 at 09:50:19AM +1300, Brent Jones wrote: > Where can I find more information on the state of iSCSI and FreeBSD? > I'm quite willing to work as a tester. If iSCSI looks like it will be > there in the next 12 months with FreeBSD, I can stick with it and not go > with Linux (I don't want to have to learn/support something new...). I came across a reference to it this afternoon in the Q3 FreeBSD status report: http://www.bsdforums.org/forums/showthread.php?t=36640 regards, Andrew From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 23 02:05:07 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A96C16A41F for ; Wed, 23 Nov 2005 02:05:07 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id B884143D45 for ; Wed, 23 Nov 2005 02:05:04 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id jAN253hp054739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Nov 2005 09:05:03 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id jAN2526j007750; Wed, 23 Nov 2005 09:05:02 +0700 (ICT) Date: Wed, 23 Nov 2005 09:05:02 +0700 (ICT) Message-Id: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-scsi@freebsd.org X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: KDying disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 02:05:07 -0000 Hi, How to read this error message? It happens more and more lately :(( This machine is running 5.4 with one hard disk SCSI 72 MB TIA Olivier Nov 22 17:42:50 ufo kernel: Copied 18 bytes of sense data offset 12: 0xf1 0x0 0x3 0x0 0x51 0x3b 0x9f 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0xd3 0x80 0x0 0x18 Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): WRITE(10). CDB: 2a 0 0 51 ac 7f 0 0 4 0 Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): CAM Status: SCSI Status Error Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): SCSI Status: Check Condition Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Deferred Error: MEDIUM ERROR info:513b9f asc:c,0 Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Write error field replaceable unit: d3 actual retry count: 24 Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Retrying Command (per Sense Data) N _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" ------- End of forwarded message ------- From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 23 02:17:32 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C0EF16A41F for ; Wed, 23 Nov 2005 02:17:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AAC43D62 for ; Wed, 23 Nov 2005 02:17:29 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAN2HCqT032352; Tue, 22 Nov 2005 19:17:12 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4383D128.1080505@samsco.org> Date: Tue, 22 Nov 2005 19:17:12 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Olivier Nicole References: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> In-Reply-To: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: KDying disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 02:17:32 -0000 Olivier Nicole wrote: > Hi, > > How to read this error message? It happens more and more lately :(( > > This machine is running 5.4 with one hard disk SCSI 72 MB > > TIA > > Olivier > > Nov 22 17:42:50 ufo kernel: Copied 18 bytes of sense data offset 12: 0xf1 0x0 0x3 0x0 0x51 0x3b 0x9f 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0xd3 0x80 0x0 0x18 > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): WRITE(10). CDB: 2a 0 0 51 ac 7f 0 0 4 0 > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): CAM Status: SCSI Status Error > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): SCSI Status: Check Condition > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Deferred Error: MEDIUM ERROR info:513b9f asc:c,0 > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Write error field replaceable unit: d3 actual retry count: 24 > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Retrying Command (per Sense Data) > N This means that you're starting to get failing sectors. The disk can automatically remap them if you are writing to them, but can't do anything if the failure occurs during a read operation. Best bet is to back up your data and look into replacing the drive. Scott From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 23 03:33:30 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B47CA16A41F for ; Wed, 23 Nov 2005 03:33:30 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E42343D7E for ; Wed, 23 Nov 2005 03:33:24 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id jAN3XIHv059261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 23 Nov 2005 10:33:18 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id jAN3XH61008638; Wed, 23 Nov 2005 10:33:17 +0700 (ICT) Date: Wed, 23 Nov 2005 10:33:17 +0700 (ICT) Message-Id: <200511230333.jAN3XH61008638@banyan.cs.ait.ac.th> From: Olivier Nicole To: freebsd-scsi@freebsd.org In-reply-to: <4383D128.1080505@samsco.org> (message from Scott Long on Tue, 22 Nov 2005 19:17:12 -0700) References: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> <4383D128.1080505@samsco.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Subject: Re: KDying disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 03:33:30 -0000 > > Nov 22 17:42:50 ufo kernel: Copied 18 bytes of sense data offset 12: 0xf1 0x0 0x3 0x0 0x51 0x3b 0x9f 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0xd3 0x80 0x0 0x18 > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): WRITE(10). CDB: 2a 0 0 51 ac 7f 0 0 4 0 > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): CAM Status: SCSI Status Error > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): SCSI Status: Check Condition > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Deferred Error: MEDIUM ERROR info:513b9f asc:c,0 > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Write error field replaceable unit: d3 actual retry count: 24 > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Retrying Command (per Sense Data) > > N > > This means that you're starting to get failing sectors. The disk can > automatically remap them if you are writing to them, but can't do Is there a way to tell what sector(s) is bad/what partition is concerned? I did a physical disk verify (from Adaptec BIOS at reboot) that detected nothing bad. I am afraid that the error message will not be an evidence good enought to claim for waranty :( Thanks, olivier From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 23 04:14:40 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E7916A420 for ; Wed, 23 Nov 2005 04:14:40 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1444F43D46 for ; Wed, 23 Nov 2005 04:14:39 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.12.11/8.12.11) with ESMTP id jAN4EE3G014647; Tue, 22 Nov 2005 21:14:14 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.12.11/8.12.5/Submit) id jAN4EEGN014646; Tue, 22 Nov 2005 21:14:14 -0700 (MST) (envelope-from ken) Date: Tue, 22 Nov 2005 21:14:14 -0700 From: "Kenneth D. Merry" To: Olivier Nicole Message-ID: <20051123041414.GA14542@nargothrond.kdm.org> References: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> <4383D128.1080505@samsco.org> <200511230333.jAN3XH61008638@banyan.cs.ait.ac.th> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511230333.jAN3XH61008638@banyan.cs.ait.ac.th> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.86.1/1184/Tue Nov 22 16:10:14 2005 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: KDying disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 04:14:40 -0000 On Wed, Nov 23, 2005 at 10:33:17 +0700, Olivier Nicole wrote: > > > Nov 22 17:42:50 ufo kernel: Copied 18 bytes of sense data offset 12: 0xf1 0x0 0x3 0x0 0x51 0x3b 0x9f 0xa 0x0 0x0 0x0 0x0 0xc 0x0 0xd3 0x80 0x0 0x18 > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): WRITE(10). CDB: 2a 0 0 51 ac 7f 0 0 4 0 > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): CAM Status: SCSI Status Error > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): SCSI Status: Check Condition > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Deferred Error: MEDIUM ERROR info:513b9f asc:c,0 > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Write error field replaceable unit: d3 actual retry count: 24 > > > Nov 22 17:42:50 ufo kernel: (da0:ahd1:0:0:0): Retrying Command (per Sense Data) > > > N > > > > This means that you're starting to get failing sectors. The disk can > > automatically remap them if you are writing to them, but can't do > > Is there a way to tell what sector(s) is bad/what partition is > concerned? The sector in question is specified in the info: field in the sense information. In this case, it's sector 0x513b9f. Note that since this is a deferred error, it generally won't have anything to do with the write that apparantly failed. (i.e. pay no attention to the CDB for the command, it's really a different command that failed) This error happens when you have write caching turned on, and the drive has already acknowledged the write with good status, but then later has problems when it actually tries to write the data to that sector on the disk. So it remaps that sector to one of its spare sectors, and informs you by throwing a deferred error on the next write command it sees. > I did a physical disk verify (from Adaptec BIOS at reboot) that > detected nothing bad. You'll probably see this block in the grown defect list. A verify probably wouldn't find a problem with that sector, since it was remapped. To see the grown defect list, try this: camcontrol defects da0 -f phys -G It'll be difficult to map the output of the physical block description (cylinder, head and sector) back to the LBA you use when talking to the disk most of the time. A few disks (not many) support the block format, so you could use -f block instead and see if that works. > I am afraid that the error message will not be an evidence good > enought to claim for waranty :( Some drive manufacturers have a disk verification utility that will generate pass/fail status for a drive. Sometimes they'll require output from that utility in order to take a drive back for warranty replacement. See if your drive manufacturer has such a utility and see what it says. (It may be a DOS or Windows utility, though...) This sort of thing is why I'd recommend some sort of RAID setup for most machines now. The cost of a disk failure in time, inconvenience and replacing the data often outweighs the cost of buying an extra disk or disks and setting up RAID (not RAID-0 :) in software or hardware. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 23 11:16:17 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E7A916A41F for ; Wed, 23 Nov 2005 11:16:17 +0000 (GMT) (envelope-from ade@lovett.com) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id E446443D4C for ; Wed, 23 Nov 2005 11:16:16 +0000 (GMT) (envelope-from ade@lovett.com) Received: from hellfire.lab.lovett.com ([10.16.32.20]:56285) by mail.lovett.com with esmtpa (Exim 4.54 (FreeBSD)) id 1Eesbn-0001Bi-Qb; Wed, 23 Nov 2005 03:16:15 -0800 In-Reply-To: <7579f7fb0509182239187fb73c@mail.gmail.com> References: <3A1FD217-5880-4845-9F64-5DD9395D1C6D@FreeBSD.org> <7579f7fb0509182239187fb73c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ade Lovett Date: Wed, 23 Nov 2005 03:16:15 -0800 To: lydianconcepts@gmail.com X-Mailer: Apple Mail (2.746.2) Sender: ade@lovett.com Cc: freebsd-scsi@freebsd.org Subject: Re: CAM tags / reset problem X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2005 11:16:17 -0000 Any further thoughts on this, chaps? Unless anyone objects strenuously, I'd like to go ahead and commit this to HEAD, give it a month or so to settle in, and then MFC to both RELENG_6 and RELENG_5. -aDe On Sep 18, 2005, at 22:39 , Matthew Jacob wrote: > I'll let Nate or Ken or Justin comment. > > On 9/17/05, Ade Lovett wrote: >> >> The observed behaviour is this: there is a bus reset during device >> probing / negotiation during boot, and after the system is up many of >> the scsi devices are found to be running with dev_openings = 1, which >> is less than the mintags = 2 setting, even though tag queueing is >> supposedly enabled. Performance is impaired as a result. >> >> The cause appears to be as follows: in cam_xpt.c, the routine >> xpt_dev_ccbq_resize saves, in dev->tag_saved_openings, the requested >> queue size _if and only if_ tag queueing is either enabled >> (SID_CmdQue >> is set) or is _scheduled_ to be enabled (CAM_DEV_TAG_AFTER_COUNT is >> set). However, the following sequence can occur: >> >> 1) Device transfer settings are negotiated. The device can support >> tags, so CAM_DEV_TAG_AFTER_COUNT is set (tag queueing is _not_ >> immediately enabled). >> >> 2) Before enough commands have been sent to cause tag queueing to be >> started, the bus is reset and all transfer settings are reset. This >> results in xpt_set_transfer_settings being called, and in turn this >> clears SID_CmdQue and calls xpt_dev_ccbq_resize (to resize the queue >> down to its non-tagged size, typically 1), and only then clears >> CAM_DEV_TAG_AFTER_COUNT (which was of course set) and its associated >> count. This causes xpt_dev_ccbq_resize to save the requested queue >> size even though it does not relate to the desired size with tag >> queueing enabled. >> >> 3) If tag-queueing is enabled again, e.g. after another negotiation, >> then the saved value (1) of tag_saved_openings is used rather than >> the correct value. >> >> The fix seems to be to clear CAM_DEV_TAG_AFTER_COUNT _before_ >> resizing >> the queue, as per the following patch: >> >> http://people.FreeBSD.org/~ade/sys-dev-cam-xpt.c >> >> I'd like permission to commit this to HEAD, followed by a relatively >> quick MFC to RELENG_6 (I know I've missed BETA5, but would like to >> get it into -RELEASE) >> >> -aDe >> >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi- >> unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-scsi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-scsi > To unsubscribe, send any mail to "freebsd-scsi- > unsubscribe@freebsd.org" > From owner-freebsd-scsi@FreeBSD.ORG Thu Nov 24 05:39:11 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D589516A41F for ; Thu, 24 Nov 2005 05:39:11 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4312C43D5A for ; Thu, 24 Nov 2005 05:39:09 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id jAO5d6nc014418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 Nov 2005 12:39:06 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id jAO5d4Z0038809; Thu, 24 Nov 2005 12:39:04 +0700 (ICT) Date: Thu, 24 Nov 2005 12:39:04 +0700 (ICT) Message-Id: <200511240539.jAO5d4Z0038809@banyan.cs.ait.ac.th> From: Olivier Nicole To: ken@kdm.org In-reply-to: <20051123041414.GA14542@nargothrond.kdm.org> (ken@kdm.org) References: <200511230205.jAN2526j007750@banyan.cs.ait.ac.th> <4383D128.1080505@samsco.org> <200511230333.jAN3XH61008638@banyan.cs.ait.ac.th> <20051123041414.GA14542@nargothrond.kdm.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) Cc: freebsd-scsi@freebsd.org Subject: Re: KDying disk X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2005 05:39:11 -0000 Hi and thanks, > You'll probably see this block in the grown defect list. A verify probably > wouldn't find a problem with that sector, since it was remapped. To see > the grown defect list, try this: > > camcontrol defects da0 -f phys -G I did that, the disk does not support the block format of course :( > > I am afraid that the error message will not be an evidence good > > enought to claim for waranty :( > > Some drive manufacturers have a disk verification utility that will > generate pass/fail status for a drive. Sometimes they'll require output I tried the Seagate tool (as the disk is Seagate) 3 times and find no error. > This sort of thing is why I'd recommend some sort of RAID setup for most > machines now. The cost of a disk failure in time, inconvenience and The spare disk is already ordered, it is somewhere in the pipe... I planned to install RAID before I had the problem, but as the machine is new I was not expecting that it was so urgent. Anyway, I installed and run smartclt, and even smartctl gives me some errors from time to time. So I am considering it could be a problem with the onboard SCSI controler rather than with the disk . Does that make any sense? TIA, Olivier ufo: smartctl -S on /dev/da0 smartctl version 5.33 [i386-portbld-freebsd5.4] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ (pass0:ahd1:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (pass0:ahd1:0:0:0): CAM Status: Command timeout Standard Inquiry (36 bytes) failed [Operation not permitted] Retrying with a 64 byte Standard Inquiry (pass0:ahd1:0:0:0): INQUIRY. CDB: 12 0 0 0 40 0 (pass0:ahd1:0:0:0): CAM Status: SCSI Bus Reset Sent/Received Standard Inquiry (64 bytes) failed [Operation not permitted] A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options. ufo: smartctl -S on /dev/da0 smartctl version 5.33 [i386-portbld-freebsd5.4] Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/ ufo: From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 05:26:19 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E147916A41F for ; Sat, 26 Nov 2005 05:26:19 +0000 (GMT) (envelope-from non_secure@yahoo.com) Received: from web50907.mail.yahoo.com (web50907.mail.yahoo.com [206.190.38.127]) by mx1.FreeBSD.org (Postfix) with SMTP id B554F43D5A for ; Sat, 26 Nov 2005 05:26:18 +0000 (GMT) (envelope-from non_secure@yahoo.com) Received: (qmail 91864 invoked by uid 60001); 26 Nov 2005 05:26:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=csg0IAyAbpnH3MoEQjkEYpeIp3ywp5x7pA7eyvXrEg4xzKYDpltnSfJaHeDPJ2v7b17P0T69u/vOloioZswBP2rElaqPrmXRBiHNhcLJFZL/tMqdt1sX1grOuvK8mLM6B9wEBbpr9ph+YYS0kRyMZe2o5rxJ2hGWcczz4cuKS6M= ; Message-ID: <20051126052618.91862.qmail@web50907.mail.yahoo.com> Received: from [24.94.196.84] by web50907.mail.yahoo.com via HTTP; Fri, 25 Nov 2005 21:26:17 PST Date: Fri, 25 Nov 2005 21:26:17 -0800 (PST) From: Joe Schmoe To: freebsd-scsi@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-questions@freebsd.org, 3waresales@amcc.com Subject: How do I use the 3dm2 CLI without a web browser ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 05:26:20 -0000 Hi, Let's play a game. Let's imagine for just one second that I am not a fucking asshole. Let's imagine that I do not want to manage my _disk drive arrays_ over a fucking web interface like a fucking little child. Let's pretend that I am a grown person, and not some bright-blinkenlights sourceforge groupie, and that I just want to run a command on the command line and get information over STDIO. Remember STDIO ? No, of course you don't - you're too busy loading KDE on your powerbook because you're too cool to use OSX, but too much of a fag not to run apple. With me so far ? Now let's say I have a 3ware array. I want to see whether it is working or not. I am used to using mlxcontrol. If nothing is wrong IT RETURNS FUCKING ZERO. Yeah - that's right - no GUI, no aqua colored desktop, and no fucking mascot. It just returns fucking zero. Or aaccli (you know, the app that won't quit on ctrl-D ? - yeah, that one) at least I can run it over ssh. So I install /usr/ports/sysutils/3dm ... and ... what ? HTML files ? gif files ? png files ? Look assholes, if I wanted a bunch of HTML and GIF and PNG files on my server, I would wget a porn site. So, now that I have mucked up my system with all of your STUPID CRAP , I run: 3dm2 Nothing. It does nothing, and now I have a 3dm2 process running in the background (presumably this is the web server for the "I just lernd linux!@" crowd and middle management) There is no man page. There is no HOWTO. There is nothing but a bunch of HTML pages and pictures. Fuck you 3ware, fuck you dead. So. My question. Is there a way to run 3dm2 on the command line, that doesn't start a daemon, that doesn't require a web browser, and that will give me information over STDIO and allow me to delete all the garbage that that port installed ? Thanks in advance! __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 07:03:52 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCA9516A41F; Sat, 26 Nov 2005 07:03:52 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from cobalt.antimatter.net (cobalt.antimatter.net [69.55.224.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE5943D55; Sat, 26 Nov 2005 07:03:52 +0000 (GMT) (envelope-from glenn@antimatter.net) Received: from glenn-mobile.antimatter.net (cpe-66-91-226-109.san.res.rr.com [66.91.226.109]) (authenticated bits=0) by cobalt.antimatter.net (8.13.4/8.13.4) with ESMTP id jAQ7XYW9032146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Nov 2005 23:33:34 -0800 X-MailKey: purple frogs are falling from the sky Message-Id: <6.2.3.4.2.20051125225452.03ec45f0@cobalt.antimatter.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Fri, 25 Nov 2005 22:59:31 -0800 To: Joe Schmoe , freebsd-scsi@freebsd.org From: Glenn Dawson In-Reply-To: <20051126052618.91862.qmail@web50907.mail.yahoo.com> References: <20051126052618.91862.qmail@web50907.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-questions@freebsd.org, 3waresales@amcc.com Subject: Re: How do I use the 3dm2 CLI without a web browser ? X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 07:03:53 -0000 At 09:26 PM 11/25/2005, Joe Schmoe wrote: >Hi, 3ware has a command line utility, it's not in ports, but you can download it from their web site. You didn't mention which 3ware product you are using, or which version of FreeBSD you have, but I suspect that this will probably work: http://www.3ware.com/support/download_9.2.1.1.asp?SNO=525 -Glenn >Thanks in advance! > > > >__________________________________ >Start your day with Yahoo! - Make it your home page! >http://www.yahoo.com/r/hs >_______________________________________________ >freebsd-questions@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-questions >To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 19:17:59 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29F1916A41F for ; Sat, 26 Nov 2005 19:17:59 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39A7A43D53 for ; Sat, 26 Nov 2005 19:17:58 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id F40FB31390; Sat, 26 Nov 2005 14:17:55 -0500 (EST) Date: Sat, 26 Nov 2005 14:17:55 -0500 (EST) From: user To: freebsd-scsi@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 19:17:59 -0000 I am going to use a Dell CERC (adaptec 2610SA 6-port) (_not_ 21610sa 16-port) SATA raid card. I am familiar with dell PERCs, and FreeBSD and RAID in generl, but I wanted to go over some of the configuration choices that the adaptec BIOS is giving me when I attempt to create a mirror: Read caching: yes/no (default is yes) (read caching does not rely on a battery, and is completely "safe", right? I am going to set this to "yes", however I wonder - why would anyone _ever_ set it to "no" ?) Write caching: enable/disable (this is the one that can get you into trouble if the system loses power before a write is committed to disk, and the battery is dead, right? I am going to set this to "disable" because I do not think the 2610SA has a battery ... right ?) Rebuild rate: high/medium/low (I have no idea what this means - I never saw this in adaptec bios before ... can anyone define exactly what this means ?) --- Any general comments / suggestions are appreciated as well. Thanks a lot. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 19:42:11 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0713716A41F for ; Sat, 26 Nov 2005 19:42:11 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECECB43D81 for ; Sat, 26 Nov 2005 19:41:56 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id jAQJfqVd004677; Sat, 26 Nov 2005 20:41:52 +0100 (CET) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id jAQJfqtJ004676; Sat, 26 Nov 2005 20:41:52 +0100 (CET) (envelope-from amon) Date: Sat, 26 Nov 2005 20:41:52 +0100 From: Herve Boulouis To: user Message-ID: <20051126194152.GA594@ra.aabs> References: Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 19:42:11 -0000 Le 26/11/2005 14:17, user a écrit: > > Read caching: yes/no (default is yes) > > (read caching does not rely on a battery, and is completely "safe", > right? I am going to set this to "yes", however I wonder - why would > anyone _ever_ set it to "no" ?) You usually want to disable read caching on all aac based adaptec raid controllers because it decreases performance. > Write caching: enable/disable > > (this is the one that can get you into trouble if the system loses power > before a write is committed to disk, and the battery is dead, right? I am > going to set this to "disable" because I do not think the 2610SA has a > battery ... right ?) If your server is plugged on a UPS you can safely enable it, it's quite a performance gain. > Rebuild rate: high/medium/low > > (I have no idea what this means - I never saw this in adaptec bios before > ... can anyone define exactly what this means ?) This controls how much ressources the card will put in rebuilding a volume that got a failed disk. A high rebuild rate will mean a short rebuild time but slower disk accesses during the rebuild. -- Herve Boulouis From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:07:06 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA0B716A41F for ; Sat, 26 Nov 2005 20:07:06 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4720343D5A for ; Sat, 26 Nov 2005 20:07:04 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id EB4C231373; Sat, 26 Nov 2005 15:07:02 -0500 (EST) Date: Sat, 26 Nov 2005 15:07:02 -0500 (EST) From: user To: Herve Boulouis In-Reply-To: <20051126194152.GA594@ra.aabs> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:07:06 -0000 On Sat, 26 Nov 2005, Herve Boulouis wrote: > Le 26/11/2005 14:17, user a =E9crit: > >=20 > > Read caching: yes/no (default is yes) > >=20 > > (read caching does not rely on a battery, and is completely "safe", > > right? I am going to set this to "yes", however I wonder - why would > > anyone _ever_ set it to "no" ?) > =20 > You usually want to disable read caching on all aac based adaptec raid > controllers because it decreases performance. Thanks - I did not know that, and that is good to know. > > Write caching: enable/disable > > > > (this is the one that can get you into trouble if the system loses powe= r > > before a write is committed to disk, and the battery is dead, right? I= am > > going to set this to "disable" because I do not think the 2610SA has a > > battery ... right ?) >=20 > If your server is plugged on a UPS you can safely enable it, it's quite > a performance gain. Ok. It is. However, my experience has been that no matter how rock solid the datacenter provided, UPS backed power is, there is a power interruption about every 1-2 years (and this experience comes from very very good datacenters - from Level3 to UUnet, etc.) ... so ... let's say I bank on this and enable write caching, how big of a deal is it when that power interruption does come ? Assuming freebsd 6.0 and UFS2 ... is it just an fsck, or is there a potential for some real problems if the kernel thinks something is totally committed, but it never makes it to the drive ? > > Rebuild rate: high/medium/low > >=20 > > (I have no idea what this means - I never saw this in adaptec bios befo= re > > ... can anyone define exactly what this means ?) >=20 > This controls how much ressources the card will put in rebuilding a volum= e > that got a failed disk. A high rebuild rate will mean a short rebuild tim= e > but slower disk accesses during the rebuild. I am going to set it to "low" then ... my experience is that a failed disk often rebuilds itself only to re-fail shortly thereafter, thus making possible a continuous loop of rebuilding over and over ... which would essentially take the system offline if all resources were dedicated to the rebuild. Comments ? thanks very much. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:22:41 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 348F416A41F for ; Sat, 26 Nov 2005 20:22:41 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E39543D5D for ; Sat, 26 Nov 2005 20:22:38 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id 51C423135F; Sat, 26 Nov 2005 15:22:37 -0500 (EST) Date: Sat, 26 Nov 2005 15:22:37 -0500 (EST) From: user To: Herve Boulouis In-Reply-To: <20051126194152.GA594@ra.aabs> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:22:41 -0000 On Sat, 26 Nov 2005, Herve Boulouis wrote: > Le 26/11/2005 14:17, user a =E9crit: > >=20 > > Read caching: yes/no (default is yes) > >=20 > > (read caching does not rely on a battery, and is completely "safe", > > right? I am going to set this to "yes", however I wonder - why would > > anyone _ever_ set it to "no" ?) > =20 > You usually want to disable read caching on all aac based adaptec raid > controllers because it decreases performance. >=20 > > Write caching: enable/disable > > > > (this is the one that can get you into trouble if the system loses powe= r > > before a write is committed to disk, and the battery is dead, right? I= am > > going to set this to "disable" because I do not think the 2610SA has a > > battery ... right ?) >=20 > If your server is plugged on a UPS you can safely enable it, it's quite > a performance gain. One other clarification - I have the option to turn write caching on and off when I create the array (I am turning it ON now for the array based on your opinion) ... but I also have an option in the adaptec bios to turn write-caching on for each specific disk drive. I have also turned this on. Are these seperate settings, or are they redundant ? (or does write caching for the array _depend on_ having write caching for each drive turned on ?) thanks. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:28:13 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4234416A41F for ; Sat, 26 Nov 2005 20:28:13 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91B2B43D45 for ; Sat, 26 Nov 2005 20:28:12 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id jAQKSCGK004885; Sat, 26 Nov 2005 21:28:12 +0100 (CET) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id jAQKSCnZ004884; Sat, 26 Nov 2005 21:28:12 +0100 (CET) (envelope-from amon) Date: Sat, 26 Nov 2005 21:28:12 +0100 From: Herve Boulouis To: user Message-ID: <20051126202812.GB594@ra.aabs> References: <20051126194152.GA594@ra.aabs> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:28:13 -0000 Le 26/11/2005 15:22, user a écrit: > > One other clarification - I have the option to turn write caching on and > off when I create the array (I am turning it ON now for the array based on > your opinion) ... but I also have an option in the adaptec bios to turn > write-caching on for each specific disk drive. I have also turned this > on. > > caching for the array _depend on_ having write caching for each drive > turned on ?) Never enable the disk write caching. The raid controller write caching is safe if you have a battery on the card or a UPS whereas the disk write cache can never be safe. -- Herve Boulouis From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:34:25 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F5FE16A41F for ; Sat, 26 Nov 2005 20:34:25 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA55C43D55 for ; Sat, 26 Nov 2005 20:34:24 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id E10BD3134F; Sat, 26 Nov 2005 15:34:23 -0500 (EST) Date: Sat, 26 Nov 2005 15:34:23 -0500 (EST) From: user To: Herve Boulouis In-Reply-To: <20051126202812.GB594@ra.aabs> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:34:25 -0000 On Sat, 26 Nov 2005, Herve Boulouis wrote: > Le 26/11/2005 15:22, user a =E9crit: > >=20 > > One other clarification - I have the option to turn write caching on an= d > > off when I create the array (I am turning it ON now for the array based= on > > your opinion) ... but I also have an option in the adaptec bios to turn > > write-caching on for each specific disk drive. I have also turned this > > on. > > > > caching for the array _depend on_ having write caching for each drive > > turned on ?) >=20 > Never enable the disk write caching. The raid controller write caching > is safe if you have a battery on the card or a UPS whereas the disk write > cache can never be safe. Can you elaborate ? I am confused as to why the UPS does not protect the disk drives just as much as it protects the raid card ? thanks a lot for your help. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:36:21 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A60CA16A41F for ; Sat, 26 Nov 2005 20:36:21 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE0D743D53 for ; Sat, 26 Nov 2005 20:36:20 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id jAQKaKOh004938; Sat, 26 Nov 2005 21:36:20 +0100 (CET) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id jAQKaKcC004937; Sat, 26 Nov 2005 21:36:20 +0100 (CET) (envelope-from amon) Date: Sat, 26 Nov 2005 21:36:20 +0100 From: Herve Boulouis To: user Message-ID: <20051126203620.GC594@ra.aabs> References: <20051126194152.GA594@ra.aabs> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:36:21 -0000 Le 26/11/2005 15:07, user a écrit: > > Ok. It is. However, my experience has been that no matter how rock solid > the datacenter provided, UPS backed power is, there is a power > interruption about every 1-2 years (and this experience comes from very > very good datacenters - from Level3 to UUnet, etc.) ... so ... let's say I American datacenters do not seem to be as reliable as (some) french ones :) > Assuming freebsd 6.0 and UFS2 ... is it just an fsck, or is there a > potential for some real problems if the kernel thinks something is totally > committed, but it never makes it to the drive ? That is impossible to predict. My personal point of view is that the performance gain is worth the risk. YMMV. > I am going to set it to "low" then ... my experience is that a failed disk > often rebuilds itself only to re-fail shortly thereafter, thus making > possible a continuous loop of rebuilding over and over ... which would > essentially take the system offline if all resources were dedicated to the > rebuild. Comments ? The controller never tries to rebuild on a failed disk. If you have dedicated spare disks it will try to rebuild the data on the spares. If you have no spare, you have to either change the failed disk or unplug and replug it if you think the failure is transient. So there is no possible loop here. -- Herve Boulouis From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:50:39 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD21616A41F for ; Sat, 26 Nov 2005 20:50:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0673C43D8A for ; Sat, 26 Nov 2005 20:50:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAQKoKCO060557; Sat, 26 Nov 2005 13:50:21 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4388CA8C.6080503@samsco.org> Date: Sat, 26 Nov 2005 13:50:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:50:39 -0000 user wrote: > > On Sat, 26 Nov 2005, Herve Boulouis wrote: > > >>Le 26/11/2005 14:17, user a �crit: >> >>>Read caching: yes/no (default is yes) >>> >>>(read caching does not rely on a battery, and is completely "safe", >>>right? I am going to set this to "yes", however I wonder - why would >>>anyone _ever_ set it to "no" ?) >> >> >>You usually want to disable read caching on all aac based adaptec raid >>controllers because it decreases performance. > > > > Thanks - I did not know that, and that is good to know. > > > >>>Write caching: enable/disable >>> >>>(this is the one that can get you into trouble if the system loses power >>>before a write is committed to disk, and the battery is dead, right? I am >>>going to set this to "disable" because I do not think the 2610SA has a >>>battery ... right ?) >> >>If your server is plugged on a UPS you can safely enable it, it's quite >>a performance gain. > > > > Ok. It is. However, my experience has been that no matter how rock solid > the datacenter provided, UPS backed power is, there is a power > interruption about every 1-2 years (and this experience comes from very > very good datacenters - from Level3 to UUnet, etc.) ... so ... let's say I > bank on this and enable write caching, how big of a deal is it when that > power interruption does come ? > > Assuming freebsd 6.0 and UFS2 ... is it just an fsck, or is there a > potential for some real problems if the kernel thinks something is totally > committed, but it never makes it to the drive ? > The problem is not with filesystem corruption, it's with parity corruption. It's possible to get a situation where a stripe is partially written out and then interrupted by a power failure, leaving the parity inconsistent with the stripe. You won't notice this until it's time to rebuild a failed drive from the parity, and then you'll get corruption. The battery on the card keeps power to the cache for a few hours until the machine brought back online and the card can flush it. Typically the batteries are very overpriced, but I guess the extra insurance is worth it and they don't wear out on machines that are kept constantly on. They wear out much faster in desktop machines that are turned off quite a bit. > > >>>Rebuild rate: high/medium/low >>> >>>(I have no idea what this means - I never saw this in adaptec bios before >>>... can anyone define exactly what this means ?) >> >>This controls how much ressources the card will put in rebuilding a volume >>that got a failed disk. A high rebuild rate will mean a short rebuild time >>but slower disk accesses during the rebuild. > Actually, what it controls is whether the firmware will insert a delay in the rebuild task after every few i/o operations, in order to give fairness to the i/o operations coming from the OS. Last I checked, it wasn't a terribly sophisticated algorithm. Performance during a rebuild is going to be horrible no matter what. What is does have a clear impact on is the performance of multiple rebuild tasks going on across the same set of disks. This isn't a terribly common occurrance, though. > > > I am going to set it to "low" then ... my experience is that a failed disk > often rebuilds itself only to re-fail shortly thereafter, thus making > possible a continuous loop of rebuilding over and over ... which would > essentially take the system offline if all resources were dedicated to the > rebuild. Comments ? It would be better to let the rebuild happen as fast as possible. Disks have a bad habit of failing in groups, and you don't want to increase the chance of a multi-disk failure by making recovery slow. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:52:53 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1789816A41F for ; Sat, 26 Nov 2005 20:52:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7490743D5A for ; Sat, 26 Nov 2005 20:52:52 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAQKqodO060577; Sat, 26 Nov 2005 13:52:50 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4388CB22.3070405@samsco.org> Date: Sat, 26 Nov 2005 13:52:50 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:52:53 -0000 user wrote: > > On Sat, 26 Nov 2005, Herve Boulouis wrote: > > >>Le 26/11/2005 14:17, user a �crit: >> >>>Read caching: yes/no (default is yes) >>> >>>(read caching does not rely on a battery, and is completely "safe", >>>right? I am going to set this to "yes", however I wonder - why would >>>anyone _ever_ set it to "no" ?) >> >> >>You usually want to disable read caching on all aac based adaptec raid >>controllers because it decreases performance. >> >> >>>Write caching: enable/disable >>> >>>(this is the one that can get you into trouble if the system loses power >>>before a write is committed to disk, and the battery is dead, right? I am >>>going to set this to "disable" because I do not think the 2610SA has a >>>battery ... right ?) >> >>If your server is plugged on a UPS you can safely enable it, it's quite >>a performance gain. > > > > One other clarification - I have the option to turn write caching on and > off when I create the array (I am turning it ON now for the array based on > your opinion) ... but I also have an option in the adaptec bios to turn > write-caching on for each specific disk drive. I have also turned this > on. > > Are these seperate settings, or are they redundant ? (or does write > caching for the array _depend on_ having write caching for each drive > turned on ?) > > thanks. > These are searate settings. The drive has a cache, and the controller has a cache. If you enable the drive cache, you really should have a UPS and a good data archive plan in place. Until a few years ago Adaptec did not enable the drive cache by default and did not recommend enabling it. Times have changed, though, but not for very good reasons. Only enable this option if you don't actually care about your data. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 20:57:56 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2431D16A41F for ; Sat, 26 Nov 2005 20:57:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74C5643D5E for ; Sat, 26 Nov 2005 20:57:53 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAQKvpSj060626; Sat, 26 Nov 2005 13:57:51 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4388CC4F.4050406@samsco.org> Date: Sat, 26 Nov 2005 13:57:51 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 20:57:56 -0000 user wrote: > I am going to use a Dell CERC (adaptec 2610SA 6-port) (_not_ 21610sa > 16-port) SATA raid card. > > I am familiar with dell PERCs, and FreeBSD and RAID in generl, but I > wanted to go over some of the configuration choices that the adaptec BIOS > is giving me when I attempt to create a mirror: > > Read caching: yes/no (default is yes) > > (read caching does not rely on a battery, and is completely "safe", > right? I am going to set this to "yes", however I wonder - why would > anyone _ever_ set it to "no" ?) > The read cache really makes no difference, and sometime decreases performance. It forces the data to make two trips across the internal adapter bus before it gets to host memory, and on many cards (i960-based ones especially), this creates horrible bottlenecks. Most modern OSes have good read caching and read-ahead algorithms, and FreeBSD is no exception. In short, this option provides little benefit except in very rare and specific situations. Scott From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 21:59:58 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F1BC16A41F for ; Sat, 26 Nov 2005 21:59:58 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id C85EF43D46 for ; Sat, 26 Nov 2005 21:59:57 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id C99C93134F; Sat, 26 Nov 2005 16:59:56 -0500 (EST) Date: Sat, 26 Nov 2005 16:59:56 -0500 (EST) From: user To: Scott Long In-Reply-To: <4388CA8C.6080503@samsco.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 21:59:58 -0000 First off, thank you very much for your help. On Sat, 26 Nov 2005, Scott Long wrote: > The problem is not with filesystem corruption, it's with parity > corruption. It's possible to get a situation where a stripe is > partially written out and then interrupted by a power failure, leaving > the parity inconsistent with the stripe. You won't notice this until > it's time to rebuild a failed drive from the parity, and then you'll > get corruption. I will only be creating mirrors. Is a mirror impervious to this, or are the potential problems even worse ? (my guess is impervious .. ?) What's the worst thing that could happen to a mirror, with write caching turned on for the array (not for the disks - I'll take your advice on not turning on write caching on the disks) that suffers a power failure ? > It would be better to let the rebuild happen as fast as possible. Disks > have a bad habit of failing in groups, and you don't want to increase > the chance of a multi-disk failure by making recovery slow. So again ... only using mirrors ... and in a two-drive chassis, I can't have a hot spare, so I am not sure if it even really matters what I set that to ... comments ? Thanks so much for your help and comments. From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 23:11:26 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B8016A41F for ; Sat, 26 Nov 2005 23:11:26 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id F396E43D46 for ; Sat, 26 Nov 2005 23:11:25 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.12.11/8.12.11) with ESMTP id jAQNBOCC043914; Sat, 26 Nov 2005 16:11:24 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.12.11/8.12.5/Submit) id jAQNBKIo043912; Sat, 26 Nov 2005 16:11:20 -0700 (MST) (envelope-from ken) Date: Sat, 26 Nov 2005 16:11:19 -0700 From: "Kenneth D. Merry" To: user Message-ID: <20051126231119.GA43846@nargothrond.kdm.org> References: <4388CA8C.6080503@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.86.1/1195/Fri Nov 25 02:29:55 2005 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 23:11:26 -0000 On Sat, Nov 26, 2005 at 16:59:56 -0500, user wrote: > > First off, thank you very much for your help. > > On Sat, 26 Nov 2005, Scott Long wrote: > > > The problem is not with filesystem corruption, it's with parity > > corruption. It's possible to get a situation where a stripe is > > partially written out and then interrupted by a power failure, leaving > > the parity inconsistent with the stripe. You won't notice this until > > it's time to rebuild a failed drive from the parity, and then you'll > > get corruption. > > > I will only be creating mirrors. Is a mirror impervious to this, or are > the potential problems even worse ? (my guess is impervious .. ?) Mirrors are not impervious to the problem. You still have the same issue; you don't know whether any outstanding data got written to all drives, some drives or no drives. If you resync the mirror, you're basically choosing one drive as "good" and the other as "suspect", regardless of what the actual situation is. > What's the worst thing that could happen to a mirror, with write caching > turned on for the array (not for the disks - I'll take your advice on not > turning on write caching on the disks) that suffers a power failure ? Assuming you don't have a battery backed cache on the controller, you may wind up with parts of your filesystem corrupted. Hopefully fsck will be able to make sense of it, but you never know. > > It would be better to let the rebuild happen as fast as possible. Disks > > have a bad habit of failing in groups, and you don't want to increase > > the chance of a multi-disk failure by making recovery slow. > > So again ... only using mirrors ... and in a two-drive chassis, I can't > have a hot spare, so I am not sure if it even really matters what I set > that to ... comments ? If you only have a two drive chassis, your best bet is to replace a failed drive as soon as you can and let the rebuild complete as soon as you can. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Sat Nov 26 23:44:17 2005 Return-Path: X-Original-To: freebsd-scsi@freebsd.org Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 191E616A41F for ; Sat, 26 Nov 2005 23:44:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 823D743D64 for ; Sat, 26 Nov 2005 23:44:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAQNi2ZL061386; Sat, 26 Nov 2005 16:44:02 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4388F341.3040700@samsco.org> Date: Sat, 26 Nov 2005 16:44:01 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kenneth D. Merry" References: <4388CA8C.6080503@samsco.org> <20051126231119.GA43846@nargothrond.kdm.org> In-Reply-To: <20051126231119.GA43846@nargothrond.kdm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, user Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2005 23:44:17 -0000 Kenneth D. Merry wrote: > On Sat, Nov 26, 2005 at 16:59:56 -0500, user wrote: > >>First off, thank you very much for your help. >> >>On Sat, 26 Nov 2005, Scott Long wrote: >> >> >>>The problem is not with filesystem corruption, it's with parity >>>corruption. It's possible to get a situation where a stripe is >>>partially written out and then interrupted by a power failure, leaving >>>the parity inconsistent with the stripe. You won't notice this until >>>it's time to rebuild a failed drive from the parity, and then you'll >>>get corruption. >> >> >>I will only be creating mirrors. Is a mirror impervious to this, or are >>the potential problems even worse ? (my guess is impervious .. ?) > > > Mirrors are not impervious to the problem. You still have the same issue; > you don't know whether any outstanding data got written to all drives, some > drives or no drives. If you resync the mirror, you're basically choosing > one drive as "good" and the other as "suspect", regardless of what the > actual situation is. > Well, it depends on how the controller recovers from improper shutdown. If it forces a full resync, you'll wind up with two drives that are consistent with each other. Whether the data on the drives represents everything that the OS thought that it wrote before the crash is a different matter, but that is no different than an unclean shutdown with only a single disk. However, if the controller doesn't do a full resync, you'll wind up with inconsistencies in the array. Take disk A1 and A2 of array A. You issue writes to sectors 1, 2, and 3 of the array. The controller caches those writes and issues them out to disks A1 and A2. Then catastrophy strikes, and only some of the sectors get written. Disk A1 has sectors 1 and 2 written, and disk A2 has sectors 2 and 3 written. The sectors that didn't get written contain old data. So now neither disk has data that is of the same age, and if a resync isn't done you'll get inconsistent read results from sectors 1 and 3. All filesystems have to deal with the fact that not all data will get to disk before a crash. Loosing cached sectors during a RAID-5 write is bad because a resync won't restore consistency. Resyncing a RAID-1 will restore consistency, even if it means that new sectors on the resync slave get overwritten by older sectors from the resync master. Having a battery for RAID-1 is definitely nice to have, but I don't view it as essential since the potential for silent data corruption isn't there. Scott