EF> dumping to dev 18,1 (offset=1090767, size=8252262):
GO>Dumping to a RAID 1 set is supported in -8. But yes, none of those
GO>values seem to align with each other. 18,1 is 'raid0b' thouugh, so that
GO>part seems correct.
MvE> offset and size relate to the dump data (dumplo and dumpsize), not
MvE> the partition.
So here are the various configs (raid0.conf from raidctl -G raid0); I omit
sd1's info (normally identical/analogous to that of sd0) because I just
pulled the disk to simulate a RAID failure. I'm unsure about whether the dump
attempt was with a healthy or (artificially) failed RAID, I think it was
with a healthy one.
start size index contents
0 1 PMBR
1 1 Pri GPT header
2 32 Pri GPT table
34 2014 Unused
2048 262144 1 GPT part - EFI System
264192 930869248 2 GPT part - NetBSD RAIDFrame component
931133440 2015 Unused
931135455 32 Sec GPT table
931135487 1 Sec GPT header
/dev/rsd0: 2 wedges:
dk0: efi0, 262144 blocks at 2048, type: msdos
dk1: raid0, 930869248 blocks at 264192, type: raidframe
# raidctl config file for /dev/rraid0
START array
# numRow numCol numSpare
1 2 0
START disks
/dev/dk1
/dev/dk3
START layout
# sectPerSU SUsPerParityUnit SUsPerReconUnit RAID_level_1
128 1 1 1
START queue
fifo 100
# /dev/rraid0:
type: RAID
disk: raid0
label: lahn
flags:
bytes/sector: 512
sectors/track: 128
tracks/cylinder: 8
sectors/cylinder: 1024
cylinders: 909051
total sectors: 930869120
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
6 partitions:
# size offset fstype [fsize bsize cpg/sgs]
a: 2097152 0 4.2BSD 0 0 0 # (Cyl. 0 - 2047)
b: 67108864 2097152 swap # (Cyl. 2048 - 67583)
d: 930869120 0 unused 0 0 # (Cyl. 0 - 909051*)
e: 62914560 69206016 4.2BSD 0 0 0 # (Cyl. 67584 - 129023)
f: 629145600 132120576 4.2BSD 0 0 0 # (Cyl. 129024 - 743423)
