From owner-freebsd-stable@FreeBSD.ORG Tue Mar 21 18:20:13 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDCC616A400; Tue, 21 Mar 2006 18:20:13 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11E8843D49; Tue, 21 Mar 2006 18:20:10 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k2LIK1YE033966; Tue, 21 Mar 2006 12:20:01 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <442043D0.6090206@centtech.com> Date: Tue, 21 Mar 2006 12:20:00 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: Mike Jakubik References: <440D74B3.3030309@vwsoft.com> <200603070939.30032.joao@matik.com.br> <54559.192.168.0.10.1141751042.squirrel@webmail.sd73.bc.ca> <20060316160813.GA15720@nowhere> <442033A2.2030208@rogers.com> In-Reply-To: <442033A2.2030208@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1347/Tue Mar 21 10:35:25 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: stable@freebsd.org, pjd@freebsd.org, Craig Boston Subject: Re: gmirror on existing filesystem (was Fresh install on gmirror'ed disks?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2006 18:20:14 -0000 Mike Jakubik wrote: > Craig Boston wrote: >> On Tue, Mar 07, 2006 at 09:04:02AM -0800, Freddie Cash wrote: >> >>> There's no need to copy files around. gmirror handles it all for you >>> behind the scenes. Just create the gmirror labels using the existing >>> disks/slices/partitions, then insert the second set of >>> disks/slices/parittions. gmirror will handle synchonising the data >>> across the mirror. >>> >> >> AFAIK, gmirror causes whatever provider it's mirroring to "lose" the >> last block to metadata. I've always avoided mirroring an existing >> filesystem for fear that shrinking a UFS filesystem's underlying device >> might cause problems down the road. >> >> Can someone with knowledge of the UFS internals please confirm one way >> or the other if this is dangerous or not? >> > > I'm curious to know this as well, as i have some systems using > gmirror, that were setup in this fashion. Could someone knowledgeable > on the matter shed some light? I've gmirrored existing disks/slices before, and it's worked fine. I'm not 100% certain about all cases, but it's possible that the filesystem could be right up against the last block of the partition, and it could get stomped on I suppose. I'm not sure what this command tells you for sure, but it dumps the last block of a slice, or disk, or whatever: dd if=/dev/ad0s3a iseek=`diskinfo ad0s3a | perl -ne '@d = split; print ($d[2]/$d[1] - 1)'` count=512 | hexdump Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------