On Thu, 16 Feb 2012, Jeremy Chadwick wrote:
On Thu, Feb 16, 2012 at 07:40:35PM -0700, Warren Block wrote:
On Thu, 16 Feb 2012, Jeremy Chadwick wrote:
On Thu, Feb 16, 2012 at 06:34:53PM -0700, Warren Block wrote:
(...Linux mdadm)
So for version 0.90 of their metadata format, you lose drive capacity by
about 64-128KBytes, given that the space is needed for metadata. For
version 1.0, I'm not sure. For version 1.1 it looks like the metadata
can be stored at the beginning.
So overall, this sounds to me like the equivalent of if GEOM was to
"lie" about the actual capacities of the devices when using classes that
require use of metadata (gmirror, etc.).
Sorry, I may be misunderstanding your point. GEOM classes don't
lie, they accurately represent the space. The space provided by a
gmirror is one block less than the actual space occupied, to allow
for the metadata block at the end. The problem is that GPT puts
backup partition tables at the end of the physical (not logical)
device. Create a GEOM device on that drive, and the GEOM metadata
overwrites the backup GPT partition table. Well, the last block of
it, anyway.
But create the GEOM device inside a GPT partition that spans the
drive, and things are fine. The GPT backup tables are safely
outside the GEOM metadata, which is safely outside of the data.
I wasn't aware you could do that. I was only aware that it was the
other way around. That (my) misconception seems to also be relayed
by others such as Miroslav who said:
GPT doesn't play nice with GEOM classes which store their metadata
on last sector. For example, you can't use gmirror of a whole drives
and use GPT on top of this mirror. (and gmirror is not the only one)
So if I read this correctly, it means that the erroneous behaviour is
the result of someone doing things "in the wrong order" (for lack of
better terminology).
Yes, or the misconception that GPT behaves the same way as GEOM
classes. (Which isn't helped by both "GPT" and "gpart"
coincidentally starting with a "g".)
However, with the methodology you describe (GEOM device inside a GPT
partition), are our bootloader bits (BTX, etc.) smart enough to figure
this out and thus be able to boot/load kernel/so forth from such a
device?
gptboot does not see the mirror, but will boot from one of the mirrored
drives. Since the drives are identical, that works. A smart boot
loader that could handle other GEOM classes is possible.
One disadvantage is that identical partitions have to be created
manually on both drives and then mirrored rather than creating a mirror
and creating a single set of partitions on it.
ae@ has an article on GPT and gmirror:
http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&sl=auto&tl=en&u=http%3A%2F%2Fbu7cher.blogspot.com%2F2011%2F03%2Ffreebsd-gmirror-gpt-ufs.html&act=url
And so do I:
http://www.wonkity.com/~wblock/docs/html/gmirror.html
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[email protected]"
