Gmirror + gpart corruption on 9.3-PRE
Warren Block
wblock at wonkity.com
Sat Jul 26 00:32:19 UTC 2014
On Fri, 25 Jul 2014, Dave Hayes wrote:
> On 07/24/2014 21:04, Warren Block wrote:
>> On Thu, 24 Jul 2014, Dave Hayes wrote:
>>
>>> At 9.3-PRERELEASE #0 r268066M I've been trying unsucessfuly to set up
>>> a brand shiny new gmirror + gpt style Raid 0 mirror using the
>>> following procedure on a disk
>>>
>>> gpart create -s gpt ada0
>>> ( shows 931G of space)
>>> gpart add -s 96G -t freebsd-swap -l swap0 ada0
>>> gpart add -t freebsd-ufs -l rw0 ada0
>>> gpart create -s gpt ada1
>>> gpart add -s 96G -t freebsd-swap -l swap1 ada1
>>> gpart add -t freebsd-ufs -l rw1 ada1
>>> gmirror label swap /dev/ada0p1 /dev/ada1p1
>>> gmirror label rw /dev/ada0p2 /dev/ada1p2
>
> I need to be clearer. Above is the point at which the corrupt table message
> is encountered. I believe the above is the equivalent of your method, and
> hence your method may not work on 9.3-PRE and above. If you happen to be able
> to test this, I'd be curious as to the results.
Just tried here with 10-STABLE, although only a single drive in the
mirror.
# gpart destroy -F da0
da0 destroyed
# gpart create -s gpt da0
da0 created
# gpart add -s 4g -t freebsd-swap -l swap0 da0
da0p1 added
# gpart add -t freebsd-ufs -l rw0 da0
da0p2 added
# gmirror label swap /dev/da0p1
# gmirror label rw /dev/da0p2
# ls /dev/mirror
ls: /dev/mirror: No such file or directory
# gmirror load
# gpart show da0
=> 34 117210173 da0 GPT (56G)
34 8388608 1 freebsd-swap (4.0G)
8388642 108821565 2 freebsd-ufs (52G)
# ls /dev/mirror
rw swap
root at lightning# gpart show da0
=> 34 117210173 da0 GPT (56G)
34 8388608 1 freebsd-swap (4.0G)
8388642 108821565 2 freebsd-ufs (52G)
# gmirror status
Name Status Components
mirror/swap COMPLETE da0p1 (ACTIVE)
mirror/rw COMPLETE da0p2 (ACTIVE)
# newfs -U /dev/mirror/rw
/dev/mirror/rw: 53135.5MB (108821560 sectors) block size 32768, fragment size 4096
using 85 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
...
# newfs -U /dev/mirror/swap
/dev/mirror/swap: 4096.0MB (8388600 sectors) block size 32768, fragment size 4096
using 7 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
...
# gpart show da0
=> 34 117210173 da0 GPT (56G)
34 8388608 1 freebsd-swap (4.0G)
8388642 108821565 2 freebsd-ufs (52G)
The 'gpart show' would have shown "corrupt" if something overwrote the
backup GPT. The only kernel messages were:
kernel: GEOM_MIRROR: Cancelling unmapped because of da0p1.
kernel: GEOM_MIRROR: Device mirror/swap launched (1/1).
kernel: GEOM_MIRROR: Cancelling unmapped because of da0p2.
kernel: GEOM_MIRROR: Device mirror/rw launched (1/1).
Now I'll create GPT partitioning inside the mirrors:
# gpart create -s gpt mirror/swap
mirror/swap created
# gpart add -s3g -t freebsd-swap mirror/swap
mirror/swapp1 added
# gpart create -s gpt mirror/rw
mirror/rw created
# gpart add -t freebsd-ufs mirror/rw
mirror/rwp1 added
# gpart show mirror/swap
=> 34 8388540 mirror/swap GPT (4.0G)
34 6291456 1 freebsd-swap (3.0G)
6291490 2097084 - free - (1.0G)
# gpart show mirror/rw
=> 34 108821497 mirror/rw GPT (52G)
34 108821497 1 freebsd-ufs (52G)
# newfs -U /dev/mirror/rwp1
/dev/mirror/rwp1: 53135.5MB (108821496 sectors) block size 32768, fragment size 4096
using 85 cylinder groups of 626.09MB, 20035 blks, 80256 inodes.
with soft updates
...
No errors. After disconnecting and reconnecting the drive:
# gpart show da0
=> 34 117210173 da0 GPT (56G)
34 8388608 1 freebsd-swap (4.0G)
8388642 108821565 2 freebsd-ufs (52G)
# gpart show mirror/swap
=> 34 8388540 mirror/swap GPT (4.0G)
34 6291456 1 freebsd-swap (3.0G)
6291490 2097084 - free - (1.0G)
# gpart show mirror/rw
=> 34 108821497 mirror/rw GPT (52G)
34 108821497 1 freebsd-ufs (52G)
This is actually working better than it should. I'm getting lost in the
recursion, but maybe comparison will help.
> I'm going to try gmirroring the entire disk and and using BSD labels for
> separate partitions. I think this will have the effect I want, and it's worth
> a test.
That would be a "dangerously dedicated" layout. It's pretty much the
same as standard MBR/bsdlabel layout, but may be less likely to boot on
modern systems.
More information about the freebsd-stable
mailing list