Re: GEOM loose end?

From: Poul-Henning Kamp <phk_at_phk.freebsd.dk>
Date: Fri, 09 May 2003 22:14:52 +0200
In message <20030509052145.GA595_at_kevad.internal>, Vallo Kallaste writes:
>Hi
>
>Several times now I've encountered following situation:
>
>I have harddisk with two slices, remaining space unallocated.
>There's FreeBSD system installed on the first slice, other one used
>as temporary storage, i.e. both have disklabel and mounted
>filesystems.
>Now I want to create third slice for whatever reasons. I know that
>it's impossible without setting special geom debugflag, so I'll set
>it kern.geom.debugflags=16. Using sysinstall I'll create the third
>slice and write new slice table down to disk. Fdisk(8) confirms that
>third slice is there. The only thing missing is now /dev entry for
>this slice, there's no /dev/adXs3. This /dev entry will be created
>when I reboot the system, but that's not acceptable. Any workaround?

Well, the loose end is in libdisk which is a loose canon.  (Sysinstall
uses libdisk.)

libdisk was built to run in "installer mode", and it was written
to be small.  It was never written as a general disk management
tool but at some point it seems to have become that, proxied by
sysinstall.

The very reason why you need to set a debug flag in geom is that
libdisk sneaks under the entire GEOM stack when it writes its changes
to the disk, and the kernel/GEOM has not been and will not be bloated
with code to detect this hack.

We _really_ need to revist the area of disk management programs,
there is a bid out there called "libwhisk" which as far as I can
tell would make a good foundation.

Unfortunately, I don't have time to work much on this issue, just
getting the kernel side and the basic tools (bsdlabel(8), sunlabel(8)
etc in shape takes most of the time I have.

Try using "bsdlabel -e" next time, it is not as hard as you might
fear.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk_at_FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Fri May 09 2003 - 11:14:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:07 UTC