Date: Fri, 23 Apr 2010 20:58:09 +0100 From: Martin Simmons <martin@lispworks.com> To: freebsd-fs@freebsd.org, avg@icyb.net.ua Subject: Re: kern.geom.debugflags=16 does NOT allow me to write to device Message-ID: <201004231958.o3NJw9hN031022@higson.cam.lispworks.com> In-Reply-To: <201004230844.58047.jhb@freebsd.org> (message from John Baldwin on Fri, 23 Apr 2010 08:44:58 -0400) References: <y2z5a1151761004221355l391c05f4qc6c0f760321b56f5@mail.gmail.com> <r2h5a1151761004230334p1f8be0cdv93c3cacf00882c2f@mail.gmail.com> <4BD191CF.40106@icyb.net.ua> <201004230844.58047.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Fri, 23 Apr 2010 08:44:58 -0400, John Baldwin said: > > On Friday 23 April 2010 8:25:51 am Andriy Gapon wrote: > > on 23/04/2010 13:34 Peter Schuller said the following: > > >> It's easy. > > > > > > Thank you for posting the example. I never really understood that > > > gpart was to be the generic tool; I thought it was gpt specific. > > > Obviously I should have read up better. > > > > > > Is gpart to be considered "tested", "stable", "production quality" > > > and/or "default" now then, or is it still cutting edge/experimental? > > > > Yes, it's "tested", "stable", "production quality" and/or "default". > > All other tools are slowly rotting now, but can be fixed to correctly works via > > GEOM interface the same way gpart does now. > > E.g. see Andrey's work on sade(8). > > Actually, the other tools were already fixed to work properly with GEOM, but > they used the older set of GEOM classes (GEOM_BSD, GEOM_MBR, etc.) instead > of the GEOM_PART classes. Ironically, disklabel is using GEOM, but sysinstall and sade are still using libdisk which does direct I/O...and also generates different BSD labels from GEOM_PART. __Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004231958.o3NJw9hN031022>