git: af433832f752 - main - geom_label: Remove an old sysinstall(8) workaround
Cy Schubert
Cy.Schubert at cschubert.com
Mon Jul 5 18:51:55 UTC 2021
In message <202107051836.165IaspD003460 at slippy.cwsent.com>, Cy Schubert
writes:
> In message <202107051517.165FHsfD012512 at gitrepo.freebsd.org>, Jessica
> Clarke wr
> ites:
> > The branch main has been updated by jrtc27:
> >
> > URL: https://cgit.FreeBSD.org/src/commit/?id=af433832f7520840c22edd1fe1266c
> 1a
> > 5cb781ad
> >
> > commit af433832f7520840c22edd1fe1266c1a5cb781ad
> > Author: Jessica Clarke <jrtc27 at FreeBSD.org>
> > AuthorDate: 2021-07-05 15:15:32 +0000
> > Commit: Jessica Clarke <jrtc27 at FreeBSD.org>
> > 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 vol
> um
> > 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 *l
> ab
> > 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.
Ok, I see the problem. The two affected machines have UFS partitions at
offset 0 of their respective slices.
--
Cheers,
Cy Schubert <Cy.Schubert at cschubert.com>
FreeBSD UNIX: <cy at FreeBSD.org> Web: https://FreeBSD.org
NTP: <cy at nwtime.org> Web: https://nwtime.org
The need of the many outweighs the greed of the few.
More information about the dev-commits-src-all
mailing list