From owner-dev-commits-src-main@freebsd.org Mon Jul 5 18:56:49 2021 Return-Path: Delivered-To: dev-commits-src-main@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 1D2E7661DEA; Mon, 5 Jul 2021 18:56:49 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4GJZfm5Sscz3N91; Mon, 5 Jul 2021 18:56:48 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id 0Ovcm7MkLFRDp0TlwmXrHt; Mon, 05 Jul 2021 18:56:48 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id 0TlumNTfH3DJA0TlvmRKWQ; Mon, 05 Jul 2021 18:56:48 +0000 X-Authority-Analysis: v=2.4 cv=FMjee8ks c=1 sm=1 tr=0 ts=60e355f0 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=kj9zAlcOel0A:10 a=e_q4qTt1xDgA:10 a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=r3DTfxH57WFLSE7fR2kA:9 a=CjuIK1q_8ugA:10 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTPS id 60171170; Mon, 5 Jul 2021 11:56:46 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.16.1/8.16.1) with ESMTP id 165IukLl003702; Mon, 5 Jul 2021 11:56:46 -0700 (PDT) (envelope-from Cy.Schubert@cschubert.com) Message-Id: <202107051856.165IukLl003702@slippy.cwsent.com> X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.7.1 Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: Jessica Clarke cc: Cy Schubert , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" Subject: Re: git: af433832f752 - main - geom_label: Remove an old sysinstall(8) workaround In-reply-to: References: <202107051517.165FHsfD012512@gitrepo.freebsd.org> <202107051836.165IaspD003460@slippy.cwsent.com> Comments: In-reply-to Jessica Clarke message dated "Mon, 05 Jul 2021 19:48:23 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Jul 2021 11:56:46 -0700 X-CMAE-Envelope: MS4xfJwRtzIMW1f5a0PeIJnSlZDQ0MPDEVMr+cEDuhbNWxRxdXWfMdBJ6Ru3B/wcDj5m1zhSYyTe30expSvuHHSklySSZhQ5p864l0BRapd5Wnux+4uEkn8Q kxeoF46qjy2BQaKUA/jyXowH5zFpLU06132S2OMzwDRLYGH0yE23E7sefVVaU/fy01RbdG8SmV9j4+IYNdqX45yfd44REN1j9ake3+Z0SL3NdzNBi5Gswdqw 7OMvBKZSE28CrPuqYQPtJtuMpa4BWK/8oi7Xk/g3BXTQb1sFsoJRDif81Fas3X2fRi5dtEJATEbWo8I9IPtIoWNSwezd5tv7Ia92QpVWmoM= X-Rspamd-Queue-Id: 4GJZfm5Sscz3N91 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: dev-commits-src-main@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Commit messages for the main branch of the src repository List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2021 18:56:49 -0000 In message , Jessica Clarke w rites: > On 5 Jul 2021, at 19:36, Cy Schubert wrote: > > > > In message <202107051517.165FHsfD012512@gitrepo.freebsd.org>, Jessica > > Clarke wr > > ites: > >> The branch main has been updated by jrtc27: > >> > >> URL: https://cgit.FreeBSD.org/src/commit/?id=af433832f7520840c22edd1fe1266 > c1a > >> 5cb781ad > >> > >> commit af433832f7520840c22edd1fe1266c1a5cb781ad > >> Author: Jessica Clarke > >> AuthorDate: 2021-07-05 15:15:32 +0000 > >> Commit: Jessica Clarke > >> CommitDate: 2021-07-05 15:15:32 +0000 > >> > >> geom_label: Remove an old sysinstall(8) workaround > >> > >> We removed sysinstall(8) back in 2011, so this workaround should be lon > g > >> since unnecessary. This workaround can end up breaking cases that are > >> hit in the real world, such as dd'ing a small pre-built disk image to a > >> large partition that you intend to grow on first boot and uses a UFS > >> disk label for / in its /etc/fstab (as the only reliable thing a raw UF > S > >> image can reference). > >> > >> Reviewed by: imp, mckusick > >> Differential Revision: https://reviews.freebsd.org/D30825 > >> --- > >> sys/geom/label/g_label_ufs.c | 35 +++++------------------------------ > >> 1 file changed, 5 insertions(+), 30 deletions(-) > >> > >> diff --git a/sys/geom/label/g_label_ufs.c b/sys/geom/label/g_label_ufs.c > >> index ababbaa4b43a..70d59488d7b6 100644 > >> --- a/sys/geom/label/g_label_ufs.c > >> +++ b/sys/geom/label/g_label_ufs.c > >> @@ -49,19 +49,8 @@ __FBSDID("$FreeBSD$"); > >> #define G_LABEL_UFS_ID 1 > >> > >> /* > >> - * G_LABEL_UFS_CMP returns true if difference between provider mediasize > >> - * and filesystem size is less than G_LABEL_UFS_MAXDIFF sectors > >> - */ > >> -#define G_LABEL_UFS_CMP(prov, fsys, size) > >> \ > >> - ( abs( ((fsys)->size) - ( (prov)->mediasize / (fsys)->fs_fsize )) \ > >> - < G_LABEL_UFS_MAXDIFF ) > >> -#define G_LABEL_UFS_MAXDIFF 0x100 > >> - > >> -/* > >> - * Try to find a superblock on the provider. If successful, then > >> - * check that the size in the superblock corresponds to the size > >> - * of the underlying provider. Finally, look for a volume label > >> - * and create an appropriate provider based on that. > >> + * Try to find a superblock on the provider. If successful, look for a vo > lum > >> e > >> + * label and create an appropriate provider based on that. > >> */ > >> static void > >> g_label_ufs_taste_common(struct g_consumer *cp, char *label, size_t size, > in > >> t what) > >> @@ -81,24 +70,10 @@ g_label_ufs_taste_common(struct g_consumer *cp, char * > lab > >> el, size_t size, int wh > >> return; > >> } > >> > >> - /* > >> - * Check for magic. We also need to check if file system size > >> - * is almost equal to providers size, because sysinstall(8) > >> - * used to bogusly put first partition at offset 0 > >> - * instead of 16, and glabel/ufs would find file system on slice > >> - * instead of partition. > >> - * > >> - * In addition, media size can be a bit bigger than file system > >> - * size. For instance, mkuzip can append bytes to align data > >> - * to large sector size (it improves compression rates). > >> - */ > >> - if (fs->fs_magic == FS_UFS1_MAGIC && fs->fs_fsize > 0 && > >> - ( G_LABEL_UFS_CMP(pp, fs, fs_old_size) > >> - || G_LABEL_UFS_CMP(pp, fs, fs_providersize))) { > >> + /* Check for magic. */ > >> + if (fs->fs_magic == FS_UFS1_MAGIC && fs->fs_fsize > 0) { > >> /* Valid UFS1. */ > >> - } else if (fs->fs_magic == FS_UFS2_MAGIC && fs->fs_fsize > 0 && > >> - ( G_LABEL_UFS_CMP(pp, fs, fs_size) > >> - || G_LABEL_UFS_CMP(pp, fs, fs_providersize))) { > >> + } else if (fs->fs_magic == FS_UFS2_MAGIC && fs->fs_fsize > 0) { > >> /* Valid UFS2. */ > >> } else { > >> goto out; > >> > > > > On one of my machines which uses UFS filesystems (sandbox) also fails: > > > > bob# ls /dev/ufs > > s10-amd64 s13-amd64 s13-amd64e test > > s11-amd64 s13-amd64a s13-amd64f testa > > s12-amd64 s13-amd64d s13-i386 > > bob# mount /alt/s11-amd64/root > > bob# ls /dev/ufs > > s10-amd64 s12-amd64 test > > s11-amd64 s13-i386 testa > > bob# > > > > After the mount of /alt/s11-amd64/root, s10-amd64 the s13-* filesystems > > become unavailble They share the same fdisk slice, using different > > bsdlabel partitions within the slice. > > > > My laptop zfs pool is on a partition in the same slice as its UFS > > filesystems. Looks like once a filesystem on a slice has been mounted, the > > other partitions within the slice are no longer available following this > > commit. > > Hm, what does bsdlabel on the disk say? My guess is your disk is set up > in the bogus manner mentioned in that comment. Is it an old machine > installed by sysinstall(8)? A little more investigation shows that on the two affected machines, UFS partitions are at offset 0 of their respective slices. For legacy environments this will require some kind of workaround or boot off a rescue disk (which I do have) to dump/recreate/restore the partitions at an offset that is not zero. The problem is quite logical. Doing the work to recreate the partitions doesn't bother me but other people may trip across this. Your call. -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org The need of the many outweighs the greed of the few.