Marin Atanasov Nikolov
2011-Feb-26 12:57 UTC
8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
Hello, I updated a system from 8.1-RELEASE to 8.2-RELEASE today and now I'm having issues with gpart and gmirror. In the past I had two non-identical disks (one 250gb and one 750gb), which I wanted to create a mirror for them, so to do this, I gpart'ed them to equal sizes and then gmirror'ed them, without any issues. Of course that means that the rest 500gb of the bigger disk is not mirrored, but that wasn't a problem, since I was keeping non-important data there. Now I've got a second 750gb disk and updated to 8.2-RELEASE, and I wanted to create a full mirror of the two disks and the problems popped up. Hope you can help me a bit here. What I did is: 1. Backed up my system 2. Booted from FixIt image 3. Removed all previous partitions for gpart. 4. Did a gmirror for ad0 Fixit# gmirror label -vb round-robin gm0 /dev/ad0 5. gpart'ed the gm0 device, so I have gm0pN partitions 6. Restored everything from the backup to the gmirror'ed partitions 7. Reboot After a reboot I get this right before the FreeBSD bootloader starts: gptboot:?invalid GPT backup header I suppose this error simply means that gpart can't find it's backup header, because gmirror and gpart both are using the last sectors for a provider to write it's metadata. Which would mean that gmirror and gpart metadata overlap, and that's why I see this message? Anyway, I can still boot from the primary GPT header, and here's the second message I get during boot: GEOM: ad0: secondary GPT header is not in the last LBA. Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've used the gmirror'ed device for gpart, not ad0. I still have another option, and that is to create partitions on the disks and then gmirror them, just like a did before without issues, and my explanation for this would be that gpart would use the last sectors of ad0 and ad1, while gmirror would use the last sectors of the partitions - ad0pN. That way I don't get any issues, but why when I want to create mirror of the whole disks I get this? Shouldn't gmirror and gpart store it's data on different sectors in that case? What would happen if I try to glabel the disks first, then gmirror and then gpart them? I guess I would mess up everything again. Should I go back to my previous setup with mirroring partitions, instead of disks? gpart now supports a `backup' option, so inserting a new disk in case of disk crash is just as simple as putting the new disk, restoring GPT tables from backup and putting the partitions in a mirror. Thanks for any feedback. Marin -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT org http://www.unix-heaven.org/
Andrey V. Elsukov
2011-Feb-26 18:15 UTC
8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 26.02.2011 15:26, Marin Atanasov Nikolov wrote:> After a reboot I get this right before the FreeBSD bootloader starts: > > gptboot: invalid GPT backup header > > I suppose this error simply means that gpart can't find it's backup > header, because gmirror and gpart both are using the last sectors for > a provider to write it's metadata.This message is from gptboot. Loader does not know about your software mirror and it just checks GPT headers in the second and last LBA. As i see now, there is inconsistency in the behavior between gptboot and GEOM_PART_GPT. gptboot does reading of GPT backup header from the last LBA, but GEOM_PART_GPT from the alternate LBA which is not equal to last LBA in your case.> Which would mean that gmirror and gpart metadata overlap, and that's > why I see this message?No.> Anyway, I can still boot from the primary GPT header, and here's the > second message I get during boot: > > GEOM: ad0: secondary GPT header is not in the last LBA. > > Why does GEOM reports ad0, and not mirror/gm0 as the provider? I've > used the gmirror'ed device for gpart, not ad0.This is how GEOM tasting works. Do you have any problem except for those messages? What does not work? Also when you are writing problem report about gpart it will be not bad to add output of `gpart show` or `gpart list` commands. And `gmirror list` for GEOM_MIRROR. -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110226/5195f6c7/signature.pgp
Andrey V. Elsukov
2011-Feb-28 17:50 UTC
8.2-RELEASE - gmirror and gpart issue. Metadata overlap?
On 28.02.2011 17:23, Joan Picanyol i Puig wrote:> http://lists.freebsd.org/pipermail/freebsd-geom/2010-July/004278.html > > 1. glabeled discs > 2. two of this previous discs are gmirrored > 3. this mirror is gparted > > We got distracted by side issues, but I believe this issue is still > present, even though I have been unable to investigate further (it might > well be that GPT specification is incompatible with gmirror'ed disks). > For your convinience the interesting bits from that thread are: > > GEOM: da1: the secondary GPT table is corrupt or invalid. > GEOM: da1: using the primary only -- recovery suggested. > > So, what explains the messages? gpart probes the disk before gmirror > (or at least it prints later on dmesg), but since the offset is in > the header, it should not even know about the gmirror + glabel part.When you create gmirror on the whole disk you have got: whole disk da0 +----------------------------------------+----+ | mirror/gm0 | MD | +----------------------------------------+----+ MD - gmirror's metadata in the last sector of da0. Now when you create GPT on the mirror/gm0: mirror/gm0 +-+-----+--------------------------+-----+ | | GPT | | GPT | +-+-----+--------------------------+-----+ When mirror/gm0 provider is tasted all is good. You got mirror with GPT without any warnings. But when da0 provider is tasted you got this: da0 +-+-----+--------------------------+-----+----+ | | GPT | | GPT | | +-+-----+--------------------------+-----+----+ This provider has one sector in the end of the disk with unknown data, but there should be secondary GPT header. First of you got a message from gptboot about corrupt GPT. The second message is from GEOM_PART that it does not like that secondary GPT located not in the end of disk. This message> GEOM: da1: the secondary GPT table is corrupt or invalid. > GEOM: da1: using the primary only -- recovery suggested.does mean that your secondary GPT header or table is lost, or it is in disagree with primary one. AFAIR, it may mean different things in 8.1 and 8.2. -- WBR, Andrey V. Elsukov -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110228/b0bbe60e/signature.pgp