From owner-freebsd-questions@freebsd.org Wed Nov 21 12:16:45 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 EB8211136C00 for ; Wed, 21 Nov 2018 12:16:44 +0000 (UTC) (envelope-from matthias@petermann-it.de) Received: from mail.d2ux.org (d2ux.org [148.251.193.221]) by mx1.freebsd.org (Postfix) with ESMTP id E43747D1BA for ; Wed, 21 Nov 2018 12:16:43 +0000 (UTC) (envelope-from matthias@petermann-it.de) Received: from mail (unknown [10.0.0.3]) by mail.d2ux.org (Postfix) with ESMTP id 404BE69C41 for ; Wed, 21 Nov 2018 13:16:43 +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 56GrteUEWf4A for ; Wed, 21 Nov 2018 13:16:42 +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 647BF69C32 for ; Wed, 21 Nov 2018 13:16:42 +0100 (CET) Subject: Re: GPT partitions on whole disk gmirror - questions about the metadata issue To: freebsd-questions@freebsd.org References: <0524022a-8776-1152-b136-e5b49897aff6@petermann-it.de> From: Matthias Petermann Message-ID: Date: Wed, 21 Nov 2018 13:16:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: <0524022a-8776-1152-b136-e5b49897aff6@petermann-it.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: E43747D1BA X-Spamd-Result: default: False [-4.21 / 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)[cached: mail.petermann-it.de]; NEURAL_HAM_SHORT(-0.92)[-0.920,0]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-1.08)[ipnet: 148.251.0.0/16(-2.50), asn: 24940(-2.88), 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 12:16:45 -0000 Hello, in the meantime I did some further research and found out that newfs has a parameter to reserve some space at the end of the to be formatted device. The manpage newfs(8) states: "-r reserved The size, in sectors, of reserved space at the end of the partition specified in special. This space will not be occupied by the file system; it can be used by other consumers such as geom(4). Defaults to 0. " Anyway, I did not see anyone using the -r parameter using for formatting a filesystem in a gmirror based device[1], and wondering at the same time as the default of "0" would mean to me that at some point - maybe only after the filesystem has filled up - it would touch the very last block on the disc and overwrite the gmirror meta data. Especially in the case of the illustrated workaround for GPT partitioned devices: +---------------------------------------------------------------------+ |+-------------------------------------------------------------------+| ||+-----------------------------------------------------------------+|| |||+---------------------------------------------------+-----------+||| |||| UFS Filesystem | gmirror |||| |||| | meta |||| |||| | data |||| |||+---------------------------------------------------+-----------+||| ||| /dev/mirror/data ||| ||+-----------------------------------------------------------------+|| || /dev/gpt/data1 || |+-------------------------------------------------------------------+| | /dev/ada0 | +---------------------------------------------------------------------+ So what is the general advice to deal with that? Is it safe to use newfs without -r and why? Kind regards, Matthias [1] http://www.wonkity.com/~wblock/docs/html/gmirror.html [2] https://forums.freebsd.org/threads/freebsd-10-2-install-with-gpt-and-gmirror.55400/ [3] https://www.ateamsystems.com/tech-blog/installing-freebsd-9-gmirror-gpt-partitions-raid-1/ Am 21.11.2018 um 05:47 schrieb Matthias Petermann: > 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 GnuPG: 0x5C3E6D75 | 5930 86EF 7965 2BBA 6572 C3D7 7B1D A3C3 5C3E 6D75