From owner-freebsd-fs@FreeBSD.ORG Thu Mar 8 12:10:42 2012 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 652FD1065675 for ; Thu, 8 Mar 2012 12:10:42 +0000 (UTC) (envelope-from davide.damico@contactlab.com) Received: from mail2.shared.smtp.contactlab.it (mail2.shared.smtp.contactlab.it [93.94.37.7]) by mx1.freebsd.org (Postfix) with ESMTP id A0E938FC18 for ; Thu, 8 Mar 2012 12:10:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; d=contactlab.com; s=s768; c=relaxed/relaxed; q=dns/txt; i=@contactlab.com; t=1331208640; h=From:Subject:Date:To:MIME-Version:Content-Type; bh=dgXEWg2tZNl1dMTN4TzPe2loD3M=; b=aV1igVNnbt7guLYWn7Cs+jwcrXRTb5/m4kAHSRRG6WP95fFy73B/I1fG2bC68vKY FLozqaZhMCw9cgaoS+4PU11wjWaTGUvsPvM0Ugnzjzbc+m4TvuYJoTnmy3KbSP4b; Received: from [213.92.90.12] ([213.92.90.12:11876] helo=mail3.tomato.it) by t.contactlab.it (envelope-from ) (ecelerity 3.2.3.43244 r(43244)) with ESMTP id 39/25-28515-0C1A85F4; Thu, 08 Mar 2012 13:10:40 +0100 Received: from mx3-master.housing.tomato.lan ([172.16.7.55]) by mail3.tomato.it with smtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5cB5-000G30-UD for freebsd-fs@freebsd.org; Thu, 08 Mar 2012 13:10:40 +0100 Received: (qmail 61688 invoked by uid 89); 8 Mar 2012 12:10:39 -0000 Received: from fast.tomato.it (HELO davepro.local) (62.101.64.91) by mx3-master.housing.tomato.lan with SMTP; 8 Mar 2012 12:10:39 -0000 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-fs@freebsd.org References: <20120308120032.C9FF11065672@hub.freebsd.org> Date: Thu, 08 Mar 2012 13:10:38 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Davide D'Amico" Organization: ContactLab Message-ID: In-Reply-To: <20120308120032.C9FF11065672@hub.freebsd.org> User-Agent: Opera Mail/11.61 (MacIntel) Subject: Re: freebsd-fs Digest, Vol 455, Issue 4 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: Thu, 08 Mar 2012 12:10:42 -0000 In data 08 marzo 2012 alle ore 13:00:32, ha scritto: > ------------------------------ > Message: 7 > Date: Thu, 8 Mar 2012 11:35:48 GMT > From: Martin Simmons > Subject: Re: FreeBSD 9 and gmirror /geom raid > To: freebsd-fs@freebsd.org > Message-ID: <201203081135.q28BZmVJ027236@higson.cam.lispworks.com> > >>>>>> On Thu, 08 Mar 2012 05:58:11 +0100, Davide D'Amico said: >> >> Il 08/03/12 00:02, Freddie Cash ha scritto: >> > On Wed, Mar 7, 2012 at 6:14 AM, Davide D'Amico >> > wrote: >> >> Hi, I have a server DELL R210 with two sata drives: >> >> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 >> >> ada0: ATA-8 SATA 2.x device >> >> ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> >> ada0: Command Queueing enabled >> >> ada0: 238418MB (488281250 512 byte sectors: 16H 63S/T 16383C) >> >> ada0: Previously was known as ad4 >> >> ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 >> >> ada1: ATA-8 SATA 2.x device >> >> ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) >> >> ada1: Command Queueing enabled >> >> ada1: 238418MB (488281250 512 byte sectors: 16H 63S/T 16383C) >> >> ada1: Previously was known as ad6 >> >> >> >> Previously (8.x) - when I didn't use a hw raid - I used to install >> freebsd >> >> in a drive (i.e. ad4), boot from it and then: >> >> >> >> # sysctl kern.geom.debugflags=16 >> >> # gmirror label -v -b round-robin data ad4 >> >> # gmirror insert data ad6 >> >> // Modification to /etc/fstab >> >> // reboot >> >> >> >> How could accomplish to the same task with 9.0-RELEASE? >> > http://people.freebsd.org/~rse/mirror/ >> > >> Hi Freddie, and thanks for your link. >> >> I followed that procedure until 9.0-RELEASE but the new installer uses >> GPT as the default partition schema, which seems incompatible with >> gmirror. >> >> I noticed in the handbook >> (http://www.freebsd.org/doc/handbook/geom-mirror.html): >> "The following procedure is also incompatible with the default >> installation settings of FreeBSD 9./X/which use the newGPTpartition >> scheme. GEOM will overwriteGPTmetadata, causing data loss and possibly >> an unbootable system." >> >> So I think that the old procedure is no more useful. > I think the problem with the old procedure is that it mirrors the whole > disk. > This fails because both gmirror and GPT store data in the last few > blocks of > the disk. > If you create gmirror(s) at the GPT partition level instead, then it > should be > safe. Yes, indeed but I would continue to mirror the entire disk, rather than single partitions. d.