From owner-freebsd-geom@FreeBSD.ORG Mon Dec 19 23:18:20 2005 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 2764816A420; Mon, 19 Dec 2005 23:18:20 +0000 (GMT) (envelope-from freebsd@walter.transip.nl) Received: from relay0.transip.nl (relay0.transip.nl [80.69.67.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 020F843D62; Mon, 19 Dec 2005 23:18:18 +0000 (GMT) (envelope-from freebsd@walter.transip.nl) Received: from quark.lfms.nl (quark.lfms.nl [81.171.100.4]) by relay0.transip.nl (Postfix) with ESMTP id 0D61223F472; Tue, 20 Dec 2005 00:18:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by quark.lfms.nl (Postfix) with ESMTP id 59D0F889163; Tue, 20 Dec 2005 00:18:11 +0100 (CET) Received: from epia.dt.lfms.nl (epia.tun.lfms.nl [172.20.4.1]) by quark.lfms.nl (Postfix) with ESMTP id 788E488900C; Tue, 20 Dec 2005 00:18:07 +0100 (CET) Received: from avalon.dt.lfms.nl (avalon.dt.lfms.nl [172.19.6.1]) by epia.dt.lfms.nl (Postfix) with ESMTP id 66DAF50BF9; Tue, 20 Dec 2005 00:18:12 +0100 (CET) Date: Tue, 20 Dec 2005 00:19:44 +0100 From: Walter Hop X-Mailer: The Bat! (v3.62.14) Professional X-Priority: 3 (Normal) Message-ID: <11510009518.20051220001944@lifeforms.nl> To: Pawel Jakub Dawidek In-Reply-To: <20051219230506.GF91822@garage.freebsd.pl> References: <1926276358.20051219235324@lifeforms.nl> <20051219230506.GF91822@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: quark.lfms.nl (amavisd-new/ClamAV/SpamAssassin) Cc: freebsd-geom@freebsd.org Subject: Re[2]: dumpon on a gmirror system 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: Mon, 19 Dec 2005 23:18:20 -0000 [in reply to pjd@FreeBSD.org, 20-12-2005] Hi Pawel, thanks for the reply! > Are you sure you mirror partitions and not slices nor whole disks? > Output of 'gmirror list' will be helpful. I am mirroring the whole drive. This is how it is setup: virt1:~# gmirror list Geom name: gm0 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 2245734875 Providers: 1. Name: mirror/gm0 Mediasize: 203928108544 (190G) Sectorsize: 512 Mode: r5w5e2 Consumers: 1. Name: ad4 Mediasize: 203928109056 (190G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 3315293457 2. Name: ad6 Mediasize: 203928109056 (190G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: DIRTY GenID: 0 SyncID: 1 ID: 3493568637 virt1:~# df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/mirror/gm0s1a 253678 104876 128508 45% / devfs 1 1 0 100% /dev /dev/mirror/gm0s1d 1012974 95224 836714 10% /var /dev/mirror/gm0s1e 253678 40 233344 0% /tmp /dev/mirror/gm0s1f 187309866 33001524 139323554 19% /usr procfs 4 4 0 100% /proc devfs 1 1 0 100% /usr/opt/httpd/dev devfs 1 1 0 100% /usr/opt/named/dev >> How do people using gmirror exclusively handle the problem of saving >> crash dumps? > > I, for one, prefer ddb(4), which is enough for me. Well, this machine is colocated, so having the machine trap to the debugger and calling a non-trained datacenter engineer to read up the output isn't very tempting :) Maybe I can hook something up serially, but it would be much better if we could just get a dump so the machine can resume its tasks quickly. > Other probably have stable systems and don't need dumps at all:) That would be nice :) I'm not even sure that it is a panic, but the problem remains despite hardware replacement so I guess something fishy is going on... Cheers, Walter Hop Transip BV -- Blaat het niet, dan schaapt het niet.