GEOM/bsdlabel regression in 8.x?

[Garrett Cooper]

On Sun, Jul 4, 2010 at 8:37 AM, Dimitry Andric <dimitry at andric.com> wrote:
> 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. :)

<offtopic>

There's a weird ass feature in geom too under 7.x+ that if you have
where if you have a dangerously dedicated disk partitioned like so
that gets mounted, it automatically hides the slicing:

$ dd if=/dev/zero of=afile bs=10m count=5
$ mdconfig -a -t vnode -f afile
md1
$ ls /dev/md1*
/dev/md1
$ sudo fdisk -BIq /dev/md1
$ bsdlabel -w /dev/md1s1
$ bsdlabel -e /dev/md1s1
# /dev/md1s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a:    96311       16    unused        0     0
  c:    96327        0    unused        0     0         # "raw" part, don't edit
# newfs /dev/md1s1
/dev/md1s1: 47.0MB (96324 sectors) block size 16384, fragment size 2048
	using 4 cylinder groups of 11.77MB, 753 blks, 1536 inodes.
super-block backups (for fsck -b #) at:
 160, 24256, 48352, 72448
$ ls /dev/md1*
/dev/md1	/dev/md1s1
$ ls /dev/md1*
/dev/md1	/dev/md1s1	/dev/md1s1a
$ mount /dev/md1s1 /mnt/mem
$ ls /dev/md1*
/dev/md1	/dev/md1s1
$ umount /mnt/mem
$ ls /dev/md1*
/dev/md1	/dev/md1s1	/dev/md1s1a

It's something that someone noticed at my work.

</offtopic>

Thanks,
-Garrett