GEOM/bsdlabel regression in 8.x?

[Dimitry Andric]

On 2010-07-04 16:26, Daniel O'Connor wrote:
>> First unmount /dev/md0s1a, or the device /dev/md0s1 will be in use, and
>> opening it for read/write (as bsdlabel probably does) will fail.
>>
>> Alternatively, you can turn on the "footshooting" debug flag in geom:
...
> It doesn't make a difference if you set that flag or not.
> 
> (The fact you need to set debugflags to modify the MBR is a separate bug anyway IMO)

On my 8-stable box, I have tried this sequence of commands:

  truncate -s 10m /tmp/test
  mdconfig -a -t vnode -f /tmp/test
  mdconfig -a -t vnode -f /tmp/test
  fdisk -BI /dev/md0
  bsdlabel -w /dev/md0s1
  bsdlabel -e /dev/md0s1
  newfs /dev/md0s1a
  mkdir /mnt/test
  mount /dev/md0s1a /mnt/test
  bsdlabel -e /dev/md0s1

The last one indeed fails, because the device is in use.  This is
expected, but the error message is very misleading, and should be
improved.

The real 'bug' (although there will probably be loads of bikesheds about
it) is probably that if you *do* unmount the filesystem, bsdlabel still
fails:

  umount /mnt/test
  bsdlabel -e /dev/md0s1
  [class not found yada yada]

Apparently, unmounting does not properly 'release' whatever underlying
geom device is preventing read/write access.  However, if you then set
the footshooting flag:

  sysctl -w kern.geom.debugflags=0x10
  bsdlabel -e /dev/md0s1

bsdlabel can write without problems, at least on my box.  Stranger
even, if you subsequently turn off the footshooting flag, it *still*
can write to the label.  That is, unless you mount and unmount the
filesystem, after which is again, sort of 'locked' against writing.

All highly confusing. :)