Date: Wed, 21 Nov 2018 11:42:39 -0800 From: freebsd@johnea.net To: freebsd-questions@freebsd.org Subject: Re: GPT partitions on whole disk gmirror - questions about the metadata issue Message-ID: <9ef2ae44-22aa-0dd8-d47b-2166ad64e749@johnea.net> In-Reply-To: <00d5a6a8-54ee-d5f8-955b-16ec3a9630e6@petermann-it.de> References: <00d5a6a8-54ee-d5f8-955b-16ec3a9630e6@petermann-it.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello Matthias, I'm very interested in this question as well, but I'm afraid I can't offer authoritative answers 8-( There is a similar subject discussed in this blog post: http://blog.frankleonhardt.com/2017/zfs-is-not-always-the-answer-bring-back-gmirror/ Mostly in the final comment at the bottom. Warren Block has offered very helpful advice regarding freebsd storage in general. Specifically these two howto's are related: http://www.wonkity.com/~wblock/docs/html/disksetup.html http://www.wonkity.com/~wblock/docs/html/gmirror.html But this conflict in the last sector remains a problem. With the broader industry scope of GPT, versus the FreeBSD specific nature of gmirror, it is obviously gmirror that will need to change if these two system are to be made cooperative. To my eye, ZFS seems heavy handed, and loaded with many features that aren't critical for my applications. (personally I liken it to btrfs) I hope the conflict of whole disk gmirror containing GPT partitions can be resolved. This GPT/gmirror conflict has been around for years now, but as the prevalence of drives > 2TB becomes almost universal, the old process of using MBR for whole disk gmirrors is becoming increasingly ineffective. I hope someone knowledgeable in the internals of gmirror can speak to your question... johnea On 11/20/18 8:47 PM, Matthias Petermann wrote: > Hello, > > in section 18.3 of the FreeBSD handbook[1] there is a warning regarding > using whole disc mirroring with gmirror together with GPT: > > "gmirror(8) stores one block of metadata at the end of the disk. Because > GPT partition schemes also store metadata at the end of the disk, > mirroring entire GPT disks with gmirror(8) is not recommended. MBR > partitioning is used here because it only stores a partition table at > the start of the disk and does not conflict with the mirror metadata." > > Why is it that gmirror does not represent the mirrored device for the > levels above it in a way that does not allow access to the last block > containing the metadata? Would it be enough to simply mimic a smaller > device, one block less than the underlying providers? > > In the case mentioned above, the workaround is to first partition both > providers using GPT and then form gmirrors from two GPT partitions each. > In this case, the metadata problem should not be critical because > gmirror exists within the partition itself. Here is my further question: > how does the file system (UFS) ensure that e.g. newfs does not overwrite > the last block of a gmirror in this setting? > > Best regards, > Matthias > > [1] https://www.freebsd.org/doc/handbook/geom-mirror.html >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9ef2ae44-22aa-0dd8-d47b-2166ad64e749>