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.=