kern.geom.debugflags=16 does NOT allow me to write to device

[John Baldwin]

On Friday 23 April 2010 11:18:58 am Ivan Voras wrote:
> On 04/23/10 14:44, John Baldwin wrote:
> > 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.
> 
> It also depends on the meaning of "fixed" :) They mostly wrote to disk 
> drives directly from userland and relied on GEOM to pick up the changes 
> via the "spoil" mechanism - which is why they couldn't write to 
> partition tables if a file system on one of the partition was mounted, 
> etc., requiring hacks like kern.geom.debugflags=16 to drop the 
> permission (actually reference counting) checks.

Not true.  They sent verb actions to the modules to write updated sectors.
Look at the write_disk() method in fdisk.c for example.  It uses a verb
for the GEOM_MBR class to update the MBR and only falls back to raw disk
access if that fails.

-- 
John Baldwin