Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 09 May 2003 22:14:52 +0200
From:      "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To:        kalts@estpak.ee
Cc:        freebsd-current@freebsd.org
Subject:   Re: GEOM loose end? 
Message-ID:  <13473.1052511292@critter.freebsd.dk>
In-Reply-To: Your message of "Fri, 09 May 2003 08:21:45 %2B0300." <20030509052145.GA595@kevad.internal> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <20030509052145.GA595@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@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.



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