From owner-freebsd-geom@FreeBSD.ORG Tue Aug 1 20:26:44 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 1C8DC16A4DF for ; Tue, 1 Aug 2006 20:26:44 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2F7743D70 for ; Tue, 1 Aug 2006 20:26:38 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k71KQXAX065577; Tue, 1 Aug 2006 15:26:33 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44CFB908.40904@centtech.com> Date: Tue, 01 Aug 2006 15:26:48 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.4 (X11/20060612) MIME-Version: 1.0 To: Lee Damon References: <44CFB4AB.4080803@castle.org> In-Reply-To: <44CFB4AB.4080803@castle.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1630/Tue Aug 1 10:38:56 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-geom@freebsd.org Subject: Re: growfs, old disks, gvinum - filesystem expansion and corruption 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: Tue, 01 Aug 2006 20:26:44 -0000 On 08/01/06 15:08, Lee Damon wrote: > I have several FreeBSD-6.1 based file servers. Each one has a hardware > RAID-based system that presents a single large (800G to 2TB) "disk" to > the OS. > > In looking around for a FBSD-supported method of slicing this disk up > into usable (and later growable) file systems the only thing I found was > gvinum. The other geom commands don't seem to deal with the idea of > slicing off parts of a large drive. > > In a process very similar to the LVM commands I've used on other systems > I set up the boxes, calved off some disk as gvinum "drives", formatted > with newfs -U /dev/gvinum/..., added data and served forth. Then as > file systems filled up I expanded those file systems. When the data was > no longer needed (testing was done, it was time to go production) I > removed those file systems by unmounting them and using rm in the gvinum > command. I then created new file systems and the time has recently come > to expand them. > > Now I discover that gvinum + growfs = Bad Things. It seems that > when a file system is grown over "old file systems" (that supposedly no > longer exist) and then fsck is run it finds those old file systems and > shoves random stuff (including device nodes in some cases) into the > lost+found directory on the current file system. fsck(8) gives many > complaints about "unexpected soft update inconsistency", unref dir", > bad/dup file", and "allocated frags marked free" & "allocated files > marked free". The rub being when I try to remove the old cruft from > lost+found I run a good probability of triggering a kernel panic. > > My questions are: > 1. Is there any way to clean up the old file system cruft without > crashing/trashing/deleting the system? You could use dd to write zeros over the old areas to wipe out the old filesystem data. Careful! > 2. What tool should I be using to calve off slices of a 'huge' drive and > later expand it? Why not use fdisk/bsdlabel? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------