Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Aug 2006 15:26:48 -0500
From:      Eric Anderson <anderson@centtech.com>
To:        Lee Damon <nomad@castle.org>
Cc:        freebsd-geom@freebsd.org
Subject:   Re: growfs, old disks, gvinum - filesystem expansion and corruption
Message-ID:  <44CFB908.40904@centtech.com>
In-Reply-To: <44CFB4AB.4080803@castle.org>
References:  <44CFB4AB.4080803@castle.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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<tm>.  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.
------------------------------------------------------------------------



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44CFB908.40904>