In message <e77f3b91-8b43-4936-affb-b96c85804...@freebsd.org>, Jessica Clarke w rites: > On 5 Jul 2021, at 19:36, Cy Schubert <cy.schub...@cschubert.com> wrote: > > > > In message <202107051517.165fhsfd012...@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 <jrt...@freebsd.org> > >> AuthorDate: 2021-07-05 15:15:32 +0000 > >> Commit: Jessica Clarke <jrt...@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 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 <cy.schub...@cschubert.com> FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org NTP: <c...@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few. _______________________________________________ dev-commits-src-main@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/dev-commits-src-main To unsubscribe, send any mail to "dev-commits-src-main-unsubscr...@freebsd.org"
