From owner-freebsd-fs@FreeBSD.ORG Tue Jun 20 23:18:40 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2BB116A47A for ; Tue, 20 Jun 2006 23:18:40 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05BB943D49 for ; Tue, 20 Jun 2006 23:18:39 +0000 (GMT) (envelope-from killing@multiplay.co.uk) Received: from vader ([212.135.219.179]) by multiplay.co.uk (multiplay.co.uk [85.236.96.23]) (MDaemon PRO v9.0.1) with ESMTP id md50002672049.msg for ; Wed, 21 Jun 2006 00:18:39 +0100 Message-ID: <009e01c694bf$d777b9d0$b3db87d4@multiplay.co.uk> From: "Steven Hartland" To: "Ensel Sharon" , References: Date: Wed, 21 Jun 2006 00:18:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Processed: multiplay.co.uk, Wed, 21 Jun 2006 00:18:39 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 212.135.219.179 X-Return-Path: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-fs@freebsd.org X-MDAV-Processed: multiplay.co.uk, Wed, 21 Jun 2006 00:18:40 +0100 Cc: Subject: Re: Adaptec 2820sa redux, and possible problems X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2006 23:18:40 -0000 Ensel Sharon wrote: > Additional tests reveal that an rsync from array0 -> array1 also > causes the kernel controller to crash, etc. > > Both arrays can survive a brutal (big, long, lots of inodes) rsync, > and they can even survive it when they are done simultaneously. They > just can't survive it to each other (although I was surprised that an > rsync over ssh behaved the same as a 'mv' or a 'cp'...) > > The good news is, it doesn't seem to be a bad card or corrupt memory > or anything, since the crash is predictable and non-randomm. > > All disk caching is turned off in the controller, and the arrays were > created with no read or write caching. There is no hardware (disk or > controller) caching going on of any kind. Any other information I can > provide ? Out of interest what disks are u using. This sounds very much like a bug that I ran into with the hpt driver turned out to be that Seagate 400GB drives dont handle 28-bit command on sector 0xfffffff correctly. Driver must use a 48-bit command to access that sector. Drives from other vendors (Maxtor, WD) don't seem to have this issue. Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk.