UFS graid and GEOM

KernelPanic

Active Member

Reaction score: 7
Messages: 117

Code:
GEOM_RAID: Promise: Array Promise created.
GEOM_RAID: Promise: Disk ada0 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Subdisk data:0-ada0 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Disk ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Subdisk data:1-ada1 state changed from NONE to ACTIVE.
GEOM_RAID: Promise: Volume started.
GEOM_RAID: Promise: Volume data state changed from STARTING to OPTIMAL.
GEOM_RAID: Promise: Provider raid/r0 for volume data created.
...
GEOM: raid/r0: the secondary GPT table is corrupt or invalid.
GEOM: raid/r0: using the primary only -- recovery suggested.
Is gmirror(8) using the secondary GPT table to store the RAID metadata and GEOM doesn't realize it or should I actually try to recover it?

There is also a message that flashes very briefly on my screen right after the loader but before the boot sequence that says something about a checksum mismatch for a partition table. Is that the same thing?
 
Last edited by a moderator:
OP
OP
K

KernelPanic

Active Member

Reaction score: 7
Messages: 117

I did it during the FreeBSD install process. I believe it was:

graid -S 930G label Promise data RAID1 ada0 ada1

After that I used the install process to create a swap and a single GPT partition on r0. The graid list information is as follows:

Code:
Geom name: Promise
State: OPTIMAL
Metadata: Promise
Providers:
1. Name: raid/r0
  Mediasize: 998579896320 (930G)
  Sectorsize: 512
  Stripesize: 4096
  Stripeoffset: 0
  Mode: r2w2e3
  Subdisks: ada0 (ACTIVE), ada1 (ACTIVE)
  Dirty: Yes
  State: OPTIMAL
  Strip: 131072
  Components: 2
  Transformation: RAID1
  RAIDLevel: RAID1
  Label: data
  descr: Promise RAID1 volume
Consumers:
1. Name: ada0
  Mediasize: 1000204886016 (932G)
  Sectorsize: 512
  Stripesize: 4096
  Stripeoffset: 0
  Mode: r1w1e1
  ReadErrors: 0
  Subdisks: r0(data):0@0
  State: ACTIVE (ACTIVE)
2. Name: ada1
  Mediasize: 1000204886016 (932G)
  Sectorsize: 512
  Stripesize: 4096
  Stripeoffset: 0
  Mode: r1w1e1
  ReadErrors: 0
  Subdisks: r0(data):1@0
  State: ACTIVE (ACTIVE)
 

kpa

Beastie's Twin

Reaction score: 1,814
Messages: 6,318

Well, the problem is that the Promise RAID metadata is very likely fighting over the last LBA sector of the hard disk with the GPT partition table that has a backup copy on the last LBA. I would use MBR partitioning or switch to gmirror(8) with individually mirrored (not whole disk) GPT partitions.
 

wblock@

Beastie Himself
Developer

Reaction score: 3,659
Messages: 13,850

The gmirror(8) metadata is smaller than the GPT backup table, but yes, they both go at the end of the drive, and conflict.
 

phoenix

Administrator
Staff member
Administrator
Moderator

Reaction score: 1,270
Messages: 4,099

I was under the impression that gmirror() metadata will use the same area as GPT partition table too.
They do. But, note how wblock@ mentioned the use of the older MBR-style partitioning when using gmirror, and didn't mention using GPT anywhere. ;)
 
Top