GEOM/bsdlabel regression in 8.x?
Garrett Cooper
yanefbsd at gmail.com
Sun Jul 4 21:15:35 UTC 2010
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
More information about the freebsd-stable
mailing list