Re: git: 076002f24d35 - main - Do comprehensive UFS/FFS superblock integrity checks when reading a superblock.
Date: Tue, 31 May 2022 03:00:35 UTC
In message <20220530231819.26E34CE@slippy.cwsent.com>, Cy Schubert writes: > 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. The two malloc()s are ok. The problem could be filesystem related. -- 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