Question about gpt tables and gmirror

CyberCr33p

CyberCr33p

I create gpt partition tables using gpart:

Code: 
/dev/ad4p1 = freebsd-boot 
/dev/ad4p2 = freebsd-ufs  /
/dev/ad4p3 = swap
/dev/ad4p4 = freebsd-ufs  /tmp
/dev/ad4p5 = freebsd-ufs  /var
/dev/ad4p6 = freebsd-ufs  /usr
/dev/ad4p7 = freebsd-ufs  /home

And on http://unix-heaven.org/node/24 I see that the author says to mirror everything but swap and freebsd-boot (bootcode)

I mirror the swap too and I also mirror the freebsd-boot partition so if one disk fails the second contains the bootcode.

I am right?
 
The other idea is to write the bootcode to the second disk too.

But is there any disadvantage to mirror the bootcode partition?
 
Mirroring swap might have performance advantages. At least if the system swaps a lot, and it depends on the type of mirror. But I didn't mirror swap, either: gmirror With Disk Partitions

Bootcode, well, how often does it change, and how hard is it to recreate? On most systems, the answers are "never" and "easy". When you create the partitions, install bootcode then. After that, well it probably won't do any harm to mirror it.

There is one thing about mirrored partitions that could be bad. If/when one drive fails and is replaced, there will be multiple copies of gmirror working hard to duplicate the existing partitions onto the new drive. That could thrash the heads a lot more than a single gmirror over a whole drive, making it much slower. I have not experimented with it, though.
 
Wouldn't mirrored swap be slower, as the kernel stripes access across all swap partitions?

I can see why mirrored swap would be better from a data safety PoV, as you could replace the dead disk live without losing the data that was in swap (which should be on disk already, but you never can be too sure).
 
Mirrors are slower on write (because both drives have to write) but can be somewhat faster on read because either drive can supply the data. Buffering and the type of mirror play into that, and how it's used. Would faster reads on swap more than make up for slower writes? Probably not, but I don't know. Now that hard drives have gone up 50%, my mirror and stripe experiments are on hold.
 
If I execute:

[cmd=]gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ad6[/cmd]

Then the second disk has the bootcode too so if the first disk breaks the server can boot from the second disk, right?
 
That is the idea, however much depends on how the BIOS interprets the intended boot order. It is possible that the system won't boot until the faulty first disk is removed and the second disk becomes the first boot device. PC BIOSs are broken in multitude of ways in this regard.
 
I will test it by disabling boot from the first disk. So I can see if it boots from the second disk.

The bios with the default settings tries to boot from the first disk first and if it can't boot from it, then to boot from the second disk.
 
Perhaps it would have been a better idea to create a gmirror from the raw disk devices, then gpt partition the resulting mirror device?

Geom would complain on boot about the secondary GPT table not being on the last sector of the disk, but it wouldn't be a fatal problem.
 
jem said:
Perhaps it would have been a better idea to create a gmirror from the raw disk devices, then gpt partition the resulting mirror device?

Geom would complain on boot about the secondary GPT table not being on the last sector of the disk, but it wouldn't be a fatal problem.
Click to expand...

The GPT spec says the backup table goes at the end of the physical drive. While gmirror and other utilities play nice, GPT does not and can overwrite the metadata at the end of the disk. So gmirror/gstripe/g-whatever inside GPT is okay, GPT inside anything else, not good. There have been some threads on the freebsd-current mailing list about this recently.
 
You must log in or register to reply here.
Back
Top