Re: git: 076002f24d35 - main - Do comprehensive UFS/FFS superblock integrity checks when reading a superblock.

In message <YpVPEtkzsKBpWtaC@albert.catwhisker.org>, David Wolfskill writes:
> 
>
> --fbDsVP+DlYRwzumm
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Mon, May 30, 2022 at 03:53:29PM -0700, Cy Schubert wrote:
> > ...
> > I don't think this is a filesystem problem. All my / filesystems trace=20
> > their ancestry back to the same machine decades ago. All were cloned at o=
> ne=20
> > point using dump | restore. All were newfs'd at some point to update from=
> =20
> > 8K blocks to 16K and eventually 32K blocksize, either using my USB rescue=
> =20
> > disk or a little bit of geom_mirror musical chairs. All four machines are=
> =20
> > consistently set up the same as each other (as much as possible consideri=
> ng=20
> > different hardware and mirrors, except for the laptop which has a single=
> =20
> > disk).
>
> I'm not disagreeing with you. :-)
>
> Providing the FS image (to Toomas) was a diagnostic aid: using it, he
> was able to reproduce the issue in his test-scaffolding environment, and
> was having some "quality time with gdb" before he needed to do other
> things (probably involving sleep).

Hmmm. How interesting.

Even after having newfs'd the filesystem and restoring it using a kernel 
and userland that did not have the commit in question I still had the 
problem.


-- 
Cheers,
Cy Schubert <Cy.Schubert@komquats.com> or <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e**(i*pi)+1=0