From owner-freebsd-geom@freebsd.org Sun Feb 7 13:51:30 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A9DF852D540 for ; Sun, 7 Feb 2021 13:51:30 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYVtn61YKz4f4L; Sun, 7 Feb 2021 13:51:29 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: by mail-yb1-xb29.google.com with SMTP id v123so11855076yba.13; Sun, 07 Feb 2021 05:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=n1Av20A53Fs5Ou4OksjI4gJcR7lp8BZHZ4u9eceRBX4=; b=ttDeYuWxnLVLMfje042XgnW6JWUF31NJ5YWre4sTwlk80mVUphW0HFE09VzPbcittE 4ziwMXegpjlVBG7fNZn2He3NeLhbQL5DGor4OHYZQQYZv0fnGUA2iCc7jnVf3xHAtgfp Lef4cfP+bYq0giuOU7ZundWwTsJXvZ3FN52GSPD7pLKw0j8tyuaMMsNuTPtignD5tFVP rJtpcRSZ5U9QL4UGsks1toZ1YchRMG6wsxqBDELzzfk2PW1yPYZL5jSSiz5FEFKxwXi4 dsTMLDj2jFxgOnB0xDQkB3vyY21GEMcHVMpuW/VtyVmjQbXYxBuyk/YmYJQFfN/awQtY czlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=n1Av20A53Fs5Ou4OksjI4gJcR7lp8BZHZ4u9eceRBX4=; b=W3WNWn+GgZOc6ONwUp9invpO2sOvkGmMijMYPrhgOetlto04ld7Ay1oGM4iyoPObl5 NCpa4Bu/fnp3NG2oRy31KFADaCDKxjarRg/ZBgf8wzSok3XlktYgieZHDyCMuQB75SKV p29tMu2GGsng6Vvy9iDh0sAOexH9jInnVaX9kt+XtDBWGy4d+VBRJnYbaoZB4a5qBf7d TY++9rCroU5TIlGHMtYZ4mkwqEEsqbPj9CNZrYX5IKL9LstB8j4xparEuw4vGrfmEh8h NxJ3MExmEdjpsMsSlVfX9VYn/dilPB3uD1/t+EwuBb2/mtn/WZR/UE+jmVC4MllTCLLm Y7pQ== X-Gm-Message-State: AOAM531XJHrZwvdS1swZruLmvo5tzFJVF5UI8iqrTweAQDuWeeN1XgOW 7cDD8kfKlzF0AGfpu+pmb0t/e1ebDJiby3Hy4TUEQLo5u6iMdg== X-Google-Smtp-Source: ABdhPJxuZgfG+2FUFMeKdtxO1hwj7YD60Y8YfGiRRjwMpUJ+QgKpotc4Q3NGRmFqGfnNy7E1uXyxn1MxC1bQeg5SK2Q= X-Received: by 2002:a25:538a:: with SMTP id h132mr18578203ybb.247.1612705888450; Sun, 07 Feb 2021 05:51:28 -0800 (PST) MIME-Version: 1.0 From: Abner Gershon <6731955@gmail.com> Date: Sun, 7 Feb 2021 08:50:52 -0500 Message-ID: Subject: Making gmirror metadata cooperate with gpt metadata To: pjd@freebsd.org, freebsd-geom@freebsd.org X-Rspamd-Queue-Id: 4DYVtn61YKz4f4L X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=ttDeYuWx; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of 6731955@gmail.com designates 2607:f8b0:4864:20::b29 as permitted sender) smtp.mailfrom=6731955@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::b29:from]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_ALL(0.00)[]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::b29:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b29:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-geom]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 13:51:30 -0000 Disclaimer, I am not a programmer but have tinkered with shell and perl scripts. Having said that, I think many would appreciate the option of using gmirror with disks larger than 2T. The reason this is currently impossible is due to GPT and gmirror both trying to store metadata in the last disk sector. MBR does not allow for partitioning of disk greater 2T. Workaround to gmirror partitions rather than whole disk is less than ideal. Lines 254-293 of geom_mirror.c =C2=AB mirror =C2=AB geom =C2=AB lib - src -= FreeBSD source tree relate to clearing and storing metadata on last sector of disk. What would be the ramifications of altering gmirror to store metadata on the 2nd to last sector? Am I looking at the correct region to alter this code? -Abner From owner-freebsd-geom@freebsd.org Sun Feb 7 20:29:05 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A03FD536737 for ; Sun, 7 Feb 2021 20:29:05 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYgjY49gwz3LB0; Sun, 7 Feb 2021 20:29:05 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mbp-2012.gromit23.net (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 170A5B1; Sun, 7 Feb 2021 15:28:59 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Making gmirror metadata cooperate with gpt metadata From: Paul Mather In-Reply-To: Date: Sun, 7 Feb 2021 15:28:58 -0500 Cc: pjd@freebsd.org, freebsd-geom@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> References: To: Abner Gershon <6731955@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4DYgjY49gwz3LB0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 20:29:05 -0000 On Feb 7, 2021, at 8:50 AM, Abner Gershon <6731955@gmail.com> wrote: > Disclaimer, I am not a programmer but have tinkered with shell and = perl > scripts. Having said that, I think many would appreciate the option of > using gmirror with disks larger than 2T. >=20 > The reason this is currently impossible is due to GPT and gmirror both > trying to store metadata in the last disk sector. >=20 > MBR does not allow for partitioning of disk greater 2T. >=20 > Workaround to gmirror partitions rather than whole disk is less than = ideal. Personally, I don't find mirroring individual partitions "less than = ideal" or at least onerous enough to enforce "whole-disk" semantics. = For one, it lets you use different balance algorithms for different = partitions, e.g., "prefer" on mirrored swap (so crash dumps work without = extra effort) and other balance algorithms for other file systems. For = another, you might potentially have to rebuild less data, depending on = the failure that leads to loss of mirror synchronisation. In a = whole-disk mirror, you are always going to have to resynchronise the = whole disk, whereas with partition-level mirrors you might be lucky and = have to resynchronise only a single partition. Also, you could turn = automatic resynchronisation off where it's not needed, e.g., for = auto-encrypted swap partitions. Gmirror's naive resilvering is also why I prefer to use ZFS for = mirroring: it resilvers (resynchronises) only actual data, and so is = much faster for pools that are emptier. (I only use gmirror for swap nowadays and use ZFS for everything else.) > Lines 254-293 of geom_mirror.c =C2=AB mirror =C2=AB geom =C2=AB lib - = src - FreeBSD source > tree > = > relate > to clearing and storing metadata on last sector of disk. >=20 > What would be the ramifications of altering gmirror to store metadata = on > the 2nd to last sector? This is basically what it ends up doing already. You make a GPT = covering the whole disk and the GPT uses the last sector for the backup. = You then make a gmirror inside this GPT container and it uses the last = sector of the container (second-to-last sector of the drive) for its = gmirror stored metadata. Also, couldn't you achieve your end using BSD partitions, or are they = disallowed inside GPT partitions? (I.e., create a GPT covering the = whole disk; create a GPT partition covering the entire GPT; create a = gmirror out of that; create a BSD partition on the gmirror for your file = systems.) Cheers, Paul.= From owner-freebsd-geom@freebsd.org Sun Feb 7 21:00:36 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4D0DB537787 for ; Sun, 7 Feb 2021 21:00:36 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4DYhPw05qpz3N4g for ; Sun, 7 Feb 2021 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.nyi.freebsd.org (Postfix) id B54A5537725; Sun, 7 Feb 2021 21:00:35 +0000 (UTC) Delivered-To: geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B379053737A for ; Sun, 7 Feb 2021 21:00:35 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYhPv1d70z3Mhn for ; Sun, 7 Feb 2021 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2FA402FA5 for ; Sun, 7 Feb 2021 21:00:34 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 117L0Y8K050194 for ; Sun, 7 Feb 2021 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 117L0Yf9050193 for geom@FreeBSD.org; Sun, 7 Feb 2021 21:00:34 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202102072100.117L0Yf9050193@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: geom@FreeBSD.org Subject: Problem reports for geom@FreeBSD.org that need special attention Date: Sun, 7 Feb 2021 21:00:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 21:00:36 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 218679 | [geli] add a verify command Open | 237269 | panic in glabel (g_label_destroy) stop after resi Open | 238814 | geom: topology lock being dropped in dumpconf of Open | 242747 | geli: AMD Epyc+GELI not using Hardware AES 4 problems total for which you should take action. From owner-freebsd-geom@freebsd.org Sun Feb 7 21:24:13 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 903E653955B for ; Sun, 7 Feb 2021 21:24:13 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYhx93XrFz3R1p for ; Sun, 7 Feb 2021 21:24:13 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: by mail-yb1-xb32.google.com with SMTP id v123so12588859yba.13 for ; Sun, 07 Feb 2021 13:24:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=qPlcT4KXK02mNCrcP/t7QTupiD75YSCQrqtJybAnf3k=; b=iPVS3iHGwb3CwLHcpXtj0x73Xa03SIa1d75xc5AX+z/0SMBODo+5NDXYyks94K0ZfC 98SSy6lDYJtvgAH+YUkByu+/lDG9xkNtRkaVT5t1EkvR7s8qqclyUx3CqFGY0eiHvsJQ G8Jcf5ogqO6kurw9H4uoiXss/xy974wT8iWdKnBUoNzea3749jiZs7L/U98Fn2/radyS nHSCB+hDUG+qw/ITwM5HeTnHMqvFpYPXZlYg7Q2T+fuerR4T4ArwvSsmz2q4qqQk6H+x yALsMOfGl2hF1xXWpWDL8lfFkCpfSbtA9ZbU79qhCEf4PtBw+HyzT8U1FagZ0IJBg0lY 3EwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=qPlcT4KXK02mNCrcP/t7QTupiD75YSCQrqtJybAnf3k=; b=oNhbAQSq5mL7Obv6IMIPi/mMWep0+Bb+90rGQ45VbOlrgYi+nuHpHEXQc+OSc+vKLY nmPsY4xfB1rTdPaIzckkXPXHduZsQ+tclPOp2WW+pKzejBN5yijsMong1uwmIrQtiytT zjUELhBiAVvlH14xW0GeiJMy7XNzT86GW7rgJt2fjfhSmGx1EMxWpRhEg0vxOSg7hcCZ 4iD/9p0I25knABgEc3Kvd1O4ArhF0rv8bdsDj4YIuneQsJX6L3Jg1K4QNMhWzANh2uiV tJngmTVtNVLnLHyMd3mbEMOvhphbKM3Bj4iPlNyqBtOvXRvMK8H2EMeJIU0WI12l5mCg 3qxQ== X-Gm-Message-State: AOAM532ivszmwGTGH3yKo9Hz6X/2dED9v8HbAIBWO6mkTfXtdXTIExIL U53d+pc9TLhcH79EbB1ItJelOznSx3yYpkg19mUz1wk7tRY= X-Google-Smtp-Source: ABdhPJzbktzEJpyjefDjJnUNXgoV8snro7K2AFlwjx/xnQFgC8N9HHqE6Yju1Xqyr6Hxeg6HPcIPq6z/eH+7QS5P5YI= X-Received: by 2002:a25:6190:: with SMTP id v138mr23338416ybb.36.1612733052284; Sun, 07 Feb 2021 13:24:12 -0800 (PST) MIME-Version: 1.0 References: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> In-Reply-To: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> From: Abner Gershon <6731955@gmail.com> Date: Sun, 7 Feb 2021 16:23:36 -0500 Message-ID: Subject: Re: Making gmirror metadata cooperate with gpt metadata To: Paul Mather , freebsd-geom@freebsd.org X-Rspamd-Queue-Id: 4DYhx93XrFz3R1p X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 21:24:13 -0000 Wow, thanks for opening my eyes to this. I did not realize that BSD partitions may be layered on top of a GPT partition. If I understand this correctly, you are suggesting I use fdisk to partition a GPT partition? BSD partitions are still limited to 2TB but that would be 2TB per GPT partition. My concern with gmirror on partition level is that I have seen a comment about how this may cause excessive stress on disk due to contention between various sectors for writing data during initial mirroring. In other words will gmirror update one partition at a time or will disk write head jitter back and forth writing 4k to 1st partition, 4k to 2nd partition, 4k to 3rd partition, etc. I have been resisting ZFS because of inefficiencies of COW for updating database files ( as opposed to updating one block of existing file ). I plan to set up a server with some UFS gmirror and some ZFS storage and do some comparisons. Will post back my results when I do. Most related posts I have seen suggest ZFS is the way of the now/future but then again I am driving a 1988 Ford ranger with manual transmission. Regards, Abner On Sun, Feb 7, 2021 at 3:28 PM Paul Mather wrote: > On Feb 7, 2021, at 8:50 AM, Abner Gershon <6731955@gmail.com> wrote: > > > Disclaimer, I am not a programmer but have tinkered with shell and perl > > scripts. Having said that, I think many would appreciate the option of > > using gmirror with disks larger than 2T. > > > > The reason this is currently impossible is due to GPT and gmirror both > > trying to store metadata in the last disk sector. > > > > MBR does not allow for partitioning of disk greater 2T. > > > > Workaround to gmirror partitions rather than whole disk is less than > ideal. > > > Personally, I don't find mirroring individual partitions "less than ideal= " > or at least onerous enough to enforce "whole-disk" semantics. For one, i= t > lets you use different balance algorithms for different partitions, e.g., > "prefer" on mirrored swap (so crash dumps work without extra effort) and > other balance algorithms for other file systems. For another, you might > potentially have to rebuild less data, depending on the failure that lead= s > to loss of mirror synchronisation. In a whole-disk mirror, you are alway= s > going to have to resynchronise the whole disk, whereas with partition-lev= el > mirrors you might be lucky and have to resynchronise only a single > partition. Also, you could turn automatic resynchronisation off where it= 's > not needed, e.g., for auto-encrypted swap partitions. > > Gmirror's naive resilvering is also why I prefer to use ZFS for mirroring= : > it resilvers (resynchronises) only actual data, and so is much faster for > pools that are emptier. > > (I only use gmirror for swap nowadays and use ZFS for everything else.) > > > > Lines 254-293 of geom_mirror.c =C2=AB mirror =C2=AB geom =C2=AB lib - s= rc - FreeBSD > source > > tree > > < > https://cgit.freebsd.org/src/tree/lib/geom/mirror/geom_mirror.c?h=3Drelen= g/13.0 > > > > relate > > to clearing and storing metadata on last sector of disk. > > > > What would be the ramifications of altering gmirror to store metadata o= n > > the 2nd to last sector? > > > This is basically what it ends up doing already. You make a GPT covering > the whole disk and the GPT uses the last sector for the backup. You then > make a gmirror inside this GPT container and it uses the last sector of t= he > container (second-to-last sector of the drive) for its gmirror stored > metadata. > > Also, couldn't you achieve your end using BSD partitions, or are they > disallowed inside GPT partitions? (I.e., create a GPT covering the whole > disk; create a GPT partition covering the entire GPT; create a gmirror ou= t > of that; create a BSD partition on the gmirror for your file systems.) > > Cheers, > > Paul. From owner-freebsd-geom@freebsd.org Sun Feb 7 22:56:00 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D3CEF53C068 for ; Sun, 7 Feb 2021 22:56:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYkz42SNRz3ncC for ; Sun, 7 Feb 2021 22:56:00 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mbp-2012.gromit23.net (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 5CBF421A; Sun, 7 Feb 2021 17:55:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Making gmirror metadata cooperate with gpt metadata From: Paul Mather In-Reply-To: Date: Sun, 7 Feb 2021 17:55:58 -0500 Cc: freebsd-geom@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <4AB2335F-706F-489D-9228-FEECFDD3CC45@gromit.dlib.vt.edu> References: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> To: Abner Gershon <6731955@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Rspamd-Queue-Id: 4DYkz42SNRz3ncC X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[73.99.214.146:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[128.173.49.70:from]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; SPAMHAUS_ZRD(0.00)[128.173.49.70:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-geom]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2021 22:56:00 -0000 On Feb 7, 2021, at 4:23 PM, Abner Gershon <6731955@gmail.com> wrote: > Wow, thanks for opening my eyes to this. I did not realize that BSD > partitions may be layered on top of a GPT partition. Hopefully it was clear from my original reply that I wasn't sure you = could do this and you should try it out for yourself (e.g., in a VM or = using an md-disk). :-) It's not clear whether it is possible from the gpart man page. For the = BSD partitioning scheme it says, "Traditional BSD disklabel, usually = used to subdivide MBR partitions. (This scheme can also be used as the = sole partitioning method, without an MBR. ..." It's not clear to me = whether you could create a partitioning scheme in this way and still = have the resultant system boot via EFI or legacy BIOS---it's the latter = "being able to boot" which is the most important, IMHO. > If I understand this correctly, you are suggesting I use fdisk to = partition > a GPT partition? No, my thought was just to add a partition of type "freebsd" inside the = GPT. I do note that the gpart man page discourages its use: "This is a = legacy partition type and should not be used for the APM or GPT = schemes." Then, as I said above, there is the matter of whether a = FreeBSD boot loader could successfully boot from such a layout. :-\ > My concern with gmirror on partition level is that I have seen a = comment > about how this may cause excessive stress on disk due to contention = between > various sectors for writing data during initial mirroring. In other = words > will gmirror update one partition at a time or will disk write head = jitter > back and forth writing 4k to 1st partition, 4k to 2nd partition, 4k to = 3rd > partition, etc. To be honest, I don't remember what it does because I only use gmirror = for swap nowadays, but I have a sneaking suspicion from memory that it = was subject to the jitter you mention (at least years ago when I was = still gmirroring UFS filesystems). I ended up turning off = autosynchronisation and doing it myself on the occasions when the mirror = broke. For initial mirroring you could make a special case for synchronising, = if you were worried about disk stress. People are increasingly using = SSDs for OS drives nowadays, so stress from mechanical head movement = becomes a moot point in that case. (In fact, all those layout and = rotational optimisations in UFS designed to minimise physical head = movement and rotational latency become moot in that case.) > I have been resisting ZFS because of inefficiencies of COW for = updating > database files ( as opposed to updating one block of existing file ). Don't databases themselves use COW techniques to ensure data safety? > I > plan to set up a server with some UFS gmirror and some ZFS storage and = do > some comparisons. Will post back my results when I do. Most related = posts I > have seen suggest ZFS is the way of the now/future but then again I am > driving a 1988 Ford ranger with manual transmission. There's nothing wrong with sticking with what you know and what you feel = comfortable with, and with what you believe best accommodates your use = case. Others in this thread have made some great points regarding not = dismissing ZFS as an option. I agree with what they said. I've used = FreeBSD since version 3 and used ZFS from the moment it was available in = FreeBSD (version 7). Here's what I would add/echo to what has already = been said as plus points for ZFS: - Pooled storage: no more gnashing teeth over badly sizing your = filesystems - Snapshots: cheap and reliable; I never felt the same way about UFS = snapshots - Flexible filesets: tune the behaviour of "filesytems" according to use = cases - Integrity and durability: advanced "RAID" setups and data integrity = protections throughout - Administration: better control over administration and delegation of = your file systems - Efficiency: tiered storage model As regards ZFS being "new," it would be fair to say that it has received = more active development in the last few years than UFS. I actually = switched from UFS to ZFS on FreeBSD/arm64 (on a 1 GB Raspberry Pi) = because I was tired of losing data due to UFS+SUJ crashing with = non-fsck-able file systems. Snapshots on UFS have also had a chequered = history of working properly (e.g., for consistent dumps). Data safety = is the #1 thing that attracts me to ZFS. Hopefully, data safety is important to you, too. Also, one big concern = I would have in changing the semantics of gmirror, as you propose, is = the easy availability of rescue tools should something happen to my = storage causing everything to go pear shaped. :-) You'd have to factor = it into your disaster recovery plan. Cheers, Paul.= From owner-freebsd-geom@freebsd.org Mon Feb 8 00:28:16 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 43A7853E6B9 for ; Mon, 8 Feb 2021 00:28:16 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DYn1W2zSTz3t2t for ; Mon, 8 Feb 2021 00:28:15 +0000 (UTC) (envelope-from 6731955@gmail.com) Received: by mail-yb1-xb33.google.com with SMTP id v123so12850502yba.13 for ; Sun, 07 Feb 2021 16:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KMjgBCr7db+H4co5/4kxLv9U3nDMEH1jqnKmBd9BTGY=; b=Xgd4eqHdfizEBcwQRasYGiydbuvXJfpSMlCaG0ov+5tzetN8rpKxpzLojpX69zQsze z5dI4qv8BXF/0wkg/H/JR+v3cV/G4T+HSZmZKZNf/9nvxGg1KGuaBwTRx2xcrsrECPjO 15fCnroXjxE8mUoIhFmzXVecmByKFV4vDktNYWMVLUjaFI0mB+Ic52CGsG2FUCuUTK5c Kvr2i1s+gRkBN6X9JjFhq1cWZ8CKjJIZk8ABuZW6Jme0+Y/BXkIwuScxgBYRjr0b2jqQ 6It4F3Bv1FHy6l+FO67BdWLFfUH+pdTis+WsVu3Q58QcupFXVmusZmaw7G87ZtY6gM03 iTYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KMjgBCr7db+H4co5/4kxLv9U3nDMEH1jqnKmBd9BTGY=; b=IpTmFCiCl2ic4/t/OFBDwmBidOiM8n3ySO187Is/M5U2aZa7CKQKljH+4PbzufnX+Y 2ki+du+tRAN2BvKfxL5cb4eBUFOpn9SKvzXZshnrpvnIlxkhYTD+Z037HEHUjBvROpQd nd4E1O7T55OnsH2vb5nYaexTNHhknXZl+g7Ky6I8IOdKjP2nU8Y88eiGi2buhBlmy3r0 0evKxrcP0coLfm1kzVEstbRVx5JhhqEG6wV0ssvS4yzPm7atgn/CD8VAAXCVLN7C/d10 fjEL/LbARFDo/7hUcxTdEV4nvzDKOWqVWFrNusHzh1dd+snJi6bz5y0I0AY8wCGvqofD XmtA== X-Gm-Message-State: AOAM531GMAI4UhxgTWuuM63z5X60asBJkFV8KRG1ZROol6EdCu1530Lr hc9NwuZ7uotmTtoDwjhWoK+w0FPcJ5naZZWvYHZKD28UsaU= X-Google-Smtp-Source: ABdhPJztSz8FeKRNdwJuAEv8Zg6eidr+K7DPDg2RlNuY+lGH/f59c/ON95dkViXpMrssc+pG8vGDFCSK+4IBCAVWodA= X-Received: by 2002:a05:6902:1025:: with SMTP id x5mr21652560ybt.21.1612744094442; Sun, 07 Feb 2021 16:28:14 -0800 (PST) MIME-Version: 1.0 References: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> <4AB2335F-706F-489D-9228-FEECFDD3CC45@gromit.dlib.vt.edu> In-Reply-To: <4AB2335F-706F-489D-9228-FEECFDD3CC45@gromit.dlib.vt.edu> From: Abner Gershon <6731955@gmail.com> Date: Sun, 7 Feb 2021 19:27:38 -0500 Message-ID: Subject: Re: Making gmirror metadata cooperate with gpt metadata To: Paul Mather Cc: freebsd-geom@freebsd.org X-Rspamd-Queue-Id: 4DYn1W2zSTz3t2t X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Xgd4eqHd; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of 6731955@gmail.com designates 2607:f8b0:4864:20::b33 as permitted sender) smtp.mailfrom=6731955@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::b33:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-geom@freebsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::b33:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b33:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-geom] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 00:28:16 -0000 Thanks for the clarifications and additional info. -Ab On Sun, Feb 7, 2021 at 5:56 PM Paul Mather wrote: > On Feb 7, 2021, at 4:23 PM, Abner Gershon <6731955@gmail.com> wrote: > > > Wow, thanks for opening my eyes to this. I did not realize that BSD > > partitions may be layered on top of a GPT partition. > > > Hopefully it was clear from my original reply that I wasn't sure you could > do this and you should try it out for yourself (e.g., in a VM or using an > md-disk). :-) > > It's not clear whether it is possible from the gpart man page. For the > BSD partitioning scheme it says, "Traditional BSD disklabel, usually used > to subdivide MBR partitions. (This scheme can also be used as the sole > partitioning method, without an MBR. ..." It's not clear to me whether you > could create a partitioning scheme in this way and still have the resultant > system boot via EFI or legacy BIOS---it's the latter "being able to boot" > which is the most important, IMHO. > > > > If I understand this correctly, you are suggesting I use fdisk to > partition > > a GPT partition? > > > No, my thought was just to add a partition of type "freebsd" inside the > GPT. I do note that the gpart man page discourages its use: "This is a > legacy partition type and should not be used for the APM or GPT schemes." > Then, as I said above, there is the matter of whether a FreeBSD boot loader > could successfully boot from such a layout. :-\ > > > > My concern with gmirror on partition level is that I have seen a comment > > about how this may cause excessive stress on disk due to contention > between > > various sectors for writing data during initial mirroring. In other words > > will gmirror update one partition at a time or will disk write head > jitter > > back and forth writing 4k to 1st partition, 4k to 2nd partition, 4k to > 3rd > > partition, etc. > > > To be honest, I don't remember what it does because I only use gmirror for > swap nowadays, but I have a sneaking suspicion from memory that it was > subject to the jitter you mention (at least years ago when I was still > gmirroring UFS filesystems). I ended up turning off autosynchronisation > and doing it myself on the occasions when the mirror broke. > > For initial mirroring you could make a special case for synchronising, if > you were worried about disk stress. People are increasingly using SSDs for > OS drives nowadays, so stress from mechanical head movement becomes a moot > point in that case. (In fact, all those layout and rotational > optimisations in UFS designed to minimise physical head movement and > rotational latency become moot in that case.) > > > > I have been resisting ZFS because of inefficiencies of COW for updating > > database files ( as opposed to updating one block of existing file ). > > > Don't databases themselves use COW techniques to ensure data safety? > > > > I > > plan to set up a server with some UFS gmirror and some ZFS storage and do > > some comparisons. Will post back my results when I do. Most related > posts I > > have seen suggest ZFS is the way of the now/future but then again I am > > driving a 1988 Ford ranger with manual transmission. > > > There's nothing wrong with sticking with what you know and what you feel > comfortable with, and with what you believe best accommodates your use case. > > Others in this thread have made some great points regarding not dismissing > ZFS as an option. I agree with what they said. I've used FreeBSD since > version 3 and used ZFS from the moment it was available in FreeBSD (version > 7). Here's what I would add/echo to what has already been said as plus > points for ZFS: > > - Pooled storage: no more gnashing teeth over badly sizing your filesystems > - Snapshots: cheap and reliable; I never felt the same way about UFS > snapshots > - Flexible filesets: tune the behaviour of "filesytems" according to use > cases > - Integrity and durability: advanced "RAID" setups and data integrity > protections throughout > - Administration: better control over administration and delegation of > your file systems > - Efficiency: tiered storage model > > As regards ZFS being "new," it would be fair to say that it has received > more active development in the last few years than UFS. I actually > switched from UFS to ZFS on FreeBSD/arm64 (on a 1 GB Raspberry Pi) because > I was tired of losing data due to UFS+SUJ crashing with non-fsck-able file > systems. Snapshots on UFS have also had a chequered history of working > properly (e.g., for consistent dumps). Data safety is the #1 thing that > attracts me to ZFS. > > Hopefully, data safety is important to you, too. Also, one big concern I > would have in changing the semantics of gmirror, as you propose, is the > easy availability of rescue tools should something happen to my storage > causing everything to go pear shaped. :-) You'd have to factor it into > your disaster recovery plan. > > Cheers, > > Paul. From owner-freebsd-geom@freebsd.org Mon Feb 8 19:01:22 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 48DA653D7D3 for ; Mon, 8 Feb 2021 19:01:22 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZFjs2Wqqz4gBD for ; Mon, 8 Feb 2021 19:01:21 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.gromit23.net (unknown [73.99.214.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 6EB2514A; Mon, 8 Feb 2021 14:01:20 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Subject: Re: Making gmirror metadata cooperate with gpt metadata From: Paul Mather In-Reply-To: Date: Mon, 8 Feb 2021 14:01:19 -0500 Cc: freebsd-geom@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5E7EFDC6-0089-4D6C-B81C-3D98A04C0FA7@gromit.dlib.vt.edu> <4AB2335F-706F-489D-9228-FEECFDD3CC45@gromit.dlib.vt.edu> To: "Kevin P. Neal" X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Rspamd-Queue-Id: 4DZFjs2Wqqz4gBD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=vt.edu (policy=none); spf=none (mx1.freebsd.org: domain of paul@gromit.dlib.vt.edu has no SPF policy when checking 128.173.49.70) smtp.mailfrom=paul@gromit.dlib.vt.edu X-Spamd-Result: default: False [-2.50 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[paul]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[128.173.49.70:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[73.99.214.146:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[128.173.49.70:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1312, ipnet:128.173.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-geom]; DMARC_POLICY_SOFTFAIL(0.10)[vt.edu : No valid SPF, No valid DKIM,none] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 19:01:22 -0000 On Feb 8, 2021, at 1:36 PM, Kevin P. Neal wrote: > On Sun, Feb 07, 2021 at 05:55:58PM -0500, Paul Mather wrote: >> To be honest, I don't remember what it does because I only use = gmirror >> for swap nowadays, but I have a sneaking suspicion from memory that = it was >=20 > Is this safe? I thought that gmirror could attempt to allocate memory, = so in > a low memory situation where you are swapping it could deadlock. Actually, I always remember the flipside: there was a time when folks = said not to swap to ZFS volumes because memory pressure from ARC could = lead to increased paging out to swap that could lead to the sort of = deadlock you mention due to even more memory pressure by ZFS. I can't remember hearing any caveats about swapping to gmirror. > Or did that only apply when using encryption? I've never had an issue swapping to a gmirror'd swap partion, encrypted = or otherwise. I build my own packages via Poudriere, which usually = guarantees giving swap a good workout. :-) Cheers, Paul.= From owner-freebsd-geom@freebsd.org Tue Feb 9 14:24:12 2021 Return-Path: Delivered-To: freebsd-geom@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 405AC5404F4 for ; Tue, 9 Feb 2021 14:24:12 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DZlWb1JPfz54tT for ; Tue, 9 Feb 2021 14:24:10 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wm1-x336.google.com with SMTP id m1so3655450wml.2 for ; Tue, 09 Feb 2021 06:24:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=CL9MTPe0NtXQ5Je6JsDLHax97O9jnVG7MUr8WfS8RlU=; b=Ac1AEd/uFcrh03GkEBy35q40bP6JDkufjfGdRVfTw/msSaMF5oAZnGL3kKNcLXvjwz v0sL/0rU4kY19Elqf8JkCyiV92LSHCMphmY9AsdtQuSp9gaOMESFoy1/qV23scdiBGYa hlbjcimVnP7pNJ+ndhkWra8cGNOio9AHDir1WrUIzdAQZi8houODD3BbVFE554nZvLLf Bl91IQ8PY+bJYSLhkH/z4yhoRNqM/havCv+48bAfHQl9uV1ajt37pD8wwycFhhLByRy6 4SGMZTtkwWFYuWfqaadVlWaBUpbCVLDyUqxT1WAyhDDlS4VxD/fEGWN0yZNvZ2MtUdV3 KAyg== X-Gm-Message-State: AOAM531Z4eacKZJgzzMXs9yONdH/8K1riToULP4eXqPpuGXZyhZVFjcN phxfz7OWBovHVkHezrxaBBVnkARI2hIUsg== X-Google-Smtp-Source: ABdhPJwSpLKGrXFat4h+Zke7TFRpL7tM8T/0v94w6ZnGRpeP2jwzsfsXUtTsfEAhFlkmu7LkqzZTdw== X-Received: by 2002:a7b:c193:: with SMTP id y19mr3671914wmi.23.1612880647585; Tue, 09 Feb 2021 06:24:07 -0800 (PST) Received: from gumby.homeunix.com ([2.124.155.25]) by smtp.gmail.com with ESMTPSA id z4sm35746366wrw.38.2021.02.09.06.24.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Feb 2021 06:24:06 -0800 (PST) Date: Tue, 9 Feb 2021 14:23:59 +0000 From: RW To: freebsd-geom@freebsd.org Subject: Re: Making gmirror metadata cooperate with gpt metadata Message-ID: <20210209142359.0310a10b@gumby.homeunix.com> In-Reply-To: References: X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4DZlWb1JPfz54tT X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.47 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; RECEIVED_SPAMHAUS_PBL(0.00)[2.124.155.25:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::336:from]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-geom@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::336:from:127.0.2.255]; NEURAL_SPAM_SHORT(0.53)[0.530]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::336:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-geom] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Feb 2021 14:24:12 -0000 On Sun, 7 Feb 2021 08:50:52 -0500 Abner Gershon wrote: > The reason this is currently impossible is due to GPT and gmirror both > trying to store metadata in the last disk sector. I don't know whether GPT with gmirror is a special case, but generally when something uses the last sector for metadata it results in a new device that's one sector smaller.