From owner-freebsd-questions@freebsd.org Wed Nov 21 04:48:07 2018 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0A684110443F for ; Wed, 21 Nov 2018 04:48:07 +0000 (UTC) (envelope-from mp@petermann-it.de) Received: from mail.d2ux.org (d2ux.org [148.251.193.221]) by mx1.freebsd.org (Postfix) with ESMTP id 582FE6E61A for ; Wed, 21 Nov 2018 04:48:05 +0000 (UTC) (envelope-from mp@petermann-it.de) Received: from mail (unknown [10.0.0.3]) by mail.d2ux.org (Postfix) with ESMTP id 7496A682D6 for ; Wed, 21 Nov 2018 05:47:58 +0100 (CET) X-Virus-Scanned: amavisd-new at petermann-it.de Received: from mail.d2ux.org ([10.0.0.3]) by mail (new.petermann-it.de [10.0.0.3]) (amavisd-new, port 10024) with ESMTP id 9Nv9nsdPTATA for ; Wed, 21 Nov 2018 05:47:57 +0100 (CET) Received: from [192.168.2.134] (p57B9DA90.dip0.t-ipconnect.de [87.185.218.144]) by mail.d2ux.org (Postfix) with ESMTPSA id C35EB682CC for ; Wed, 21 Nov 2018 05:47:57 +0100 (CET) To: freebsd-questions@freebsd.org From: Matthias Petermann Subject: GPT partitions on whole disk gmirror - questions about the metadata issue Message-ID: <00d5a6a8-54ee-d5f8-955b-16ec3a9630e6@petermann-it.de> Date: Wed, 21 Nov 2018 05:47:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 582FE6E61A X-Spamd-Result: default: False [-4.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:148.251.193.221/32]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[petermann-it.de]; MX_GOOD(-0.01)[mail.petermann-it.de]; NEURAL_HAM_SHORT(-0.86)[-0.858,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-1.06)[ipnet: 148.251.0.0/16(-2.43), asn: 24940(-2.85), country: DE(-0.01)]; ASN(0.00)[asn:24940, ipnet:148.251.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 04:48:07 -0000 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 -- Matthias Petermann | www.petermann-it.de Innovative IT-Lösungen, Systemintegration, FreeBSD/Unix-Support Wildparkring 13, 01458 Ottendorf-Okrilla | Tel.: +49 (0)35205 597 991 GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75