svn commit: r302985 - head/sys/geom/label

Maxim Sobolev sobomax at freebsd.org
Mon Jul 18 14:25:18 UTC 2016


Andrey, are you talking about this:

---
r156299 | pjd | 2006-03-04 11:41:54 -0800 (сб, 04 мар 2006) | 11 lines

We need to check if file system size is equal to provider's size, because
sysinstall(8) still bogusly puts first partition at offset 0 instead of 16,
so glabel/ufs will find file system on slice instead of partition.

Before sysinstall is fixed, we must keep this code, which means that we
wont't be able to detect UFS file systems created with 'newfs -s ...'.

PS. bsdlabel(8) creates partitions properly.

MFC after:      3 days
---

In which case this particular change has a better chance of working since
it's not removing this check but making it less strict. Therefore it might
attach to a wrong provider only if first UFS slice is the only one slice on
partition (or if the other partition is very small - less than 256 blocks
in size). In either of those cases I don't think it makes much difference
if we are attaching to a slice or a partition.

-Maxim

On Sun, Jul 17, 2016 at 10:37 PM, Andrey V. Elsukov <bu7cher at yandex.ru>
wrote:

> On 18.07.16 08:00, Maxim Sobolev wrote:
> > Author: sobomax
> > Date: Mon Jul 18 05:00:01 2016
> > New Revision: 302985
> > URL: https://svnweb.freebsd.org/changeset/base/302985
> >
> > Log:
> >   Relax checking if the privider size matches size recorded in the
> >   superblock, allowing provider to be bit bigger, i.e. have some
> >   extra padding after the FS image. That in some cases might be
> >   a side-effect of using CLOOP format which enforces certain block
> >   size and trying to compress image that is not exactly the number
> >   of those blocks in size. The UFS itself does not have any issues
> >   mounting such padded file systems, so it's what GEOM_LABEL should
> >   do.
>
> While you are thinking this is good fix, I expect that this change will
> break many installations. This is not first time when this check was
> changed.
>
> --
> WBR, Andrey V. Elsukov
>
>


More information about the svn-src-all mailing list