growfs, old disks, gvinum - filesystem expansion and corruption
Eric Anderson
anderson at centtech.com
Tue Aug 1 20:26:44 UTC 2006
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.
------------------------------------------------------------------------
More information about the freebsd-geom
mailing list