Date: Mon, 18 Jul 2016 07:24:42 -0700 From: Maxim Sobolev <sobomax@freebsd.org> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r302985 - head/sys/geom/label Message-ID: <CAH7qZftQg4TDyGC_kMPVcHpinK_Q_JvKZ-uQXzim16SOFnw%2BPQ@mail.gmail.com> In-Reply-To: <20ae3dfe-96f4-c897-67d0-71bb94d14858@yandex.ru> References: <201607180500.u6I501CX063743@repo.freebsd.org> <20ae3dfe-96f4-c897-67d0-71bb94d14858@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrey, are you talking about this: --- r156299 | pjd | 2006-03-04 11:41:54 -0800 (=D1=81=D0=B1, 04 =D0=BC=D0=B0=D1= =80 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@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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAH7qZftQg4TDyGC_kMPVcHpinK_Q_JvKZ-uQXzim16SOFnw%2BPQ>