From owner-freebsd-geom@FreeBSD.ORG Sat Aug 5 18:33:18 2006 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E50816A4EE for ; Sat, 5 Aug 2006 18:33:18 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from home.quip.cz (grimm.quip.cz [213.220.192.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37C4143DAC for ; Sat, 5 Aug 2006 18:31:24 +0000 (GMT) (envelope-from 000.fbsd@quip.cz) Received: from [192.168.1.2] (qwork.quip.test [192.168.1.2]) by home.quip.cz (Postfix) with ESMTP id 54BE153AB; Sat, 5 Aug 2006 20:31:15 +0200 (CEST) Message-ID: <44D4E3F2.5060709@quip.cz> Date: Sat, 05 Aug 2006 20:31:14 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: cs, cz, en, en-us MIME-Version: 1.0 To: rick-freebsd@kiwi-computer.com References: <44D06650.1030803@quip.cz> <20060802183001.GA14279@megan.kiwi-computer.com> <44D10D1D.9040700@quip.cz> <20060802210709.GA15310@megan.kiwi-computer.com> <44D126EF.9070503@quip.cz> <44D12A80.9040802@quip.cz> <20060802233255.GB16385@megan.kiwi-computer.com> <44D1BE0B.9090709@quip.cz> <20060803171025.GA23405@megan.kiwi-computer.com> In-Reply-To: <20060803171025.GA23405@megan.kiwi-computer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: gmirror Cannot add disk ad5 to gm0 (error=22) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2006 18:33:18 -0000 Rick C. Petty wrote: > On Thu, Aug 03, 2006 at 11:12:43AM +0200, Miroslav Lachman wrote: [...] > This certainly sounds like a disk-related problem. Likely your previous > failures were due to the same problems. Time to send the disks back to the > manufacturer for replacement.. :-/ Disk was replaced with new one and synchronization was much slower then usual (more than 5 hours instead of 1:30) If I run gstat, disks are idle (0% busy), then I star dd command to write some test file to disk and see that dd writing is about 10 times slower then on another "single disk" system. root@track = 2x 250GB Seagate SATA disks in gmirror + P4 3GHz + 1GB RAM root@grimm2 = 1x 300GB Samsung ATA disk + AMD Burton 2500 + 256MB RAM both machines has 6.1-RELEASE and similar disk partitions root@track /vol0/# dd if=/dev/zero of=/vol0/test bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 1.639139 secs (6397114 bytes/sec) root@track /vol0/# dd if=/dev/zero of=/vol0/test bs=1m count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 24.923024 secs (5385291 bytes/sec) root@track /vol0/# dd if=/dev/zero of=/vol0/test bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 190.751349 secs (5629013 bytes/sec) root@grimm2 ~/# dd if=/dev/zero of=/vol0/test bs=1m count=10 10+0 records in 10+0 records out 10485760 bytes transferred in 0.173180 secs (60548295 bytes/sec) root@grimm2 ~/# dd if=/dev/zero of=/vol0/test bs=1m count=128 128+0 records in 128+0 records out 134217728 bytes transferred in 2.479431 secs (54132468 bytes/sec) root@grimm2 ~/# dd if=/dev/zero of=/vol0/test bs=1m count=1024 1024+0 records in 1024+0 records out 1073741824 bytes transferred in 21.136426 secs (50800539 bytes/sec) grimm2 is almost 10 times faster! Is it expected, that gmirror is 10 time slower? I don't think so. Does anybody know how can I "debug" this slowness? >>After manual reboot, there is no ad5 device. I hope new drive helps, but >>I am still nervous, because I have similar troubles with 2 machines >>(both replaced with new one - so I played with 4 machines)... > > > Chance of one "new" disk being bad-- pretty low. > Chance of two new disks being bad-- even lower. > Chance of three or more disks going bad around the same time-- much higher. > > I've noticed this type of behavior before. Someone correct me if I'm > wrong but it appears that you probably got a bad batch of disks. Try > throwing a different set of disks on the boxes (preferrably a different > manufacturer). I would also try swapping with brand new high-quality > cables (just because they're cheaper than new disks). > > -- Rick C. Petty Thanks for your time and help If anything can goes bad, then everything will go bad :( (I am sorry if my english is bad, I think you know what I mean)