In article <20200827213416.ga25...@netbsd.org>,
David Holland <dholland-t...@netbsd.org> wrote:
>On Mon, Aug 24, 2020 at 12:01:27PM +0100, David Brownlee wrote:
> > > > I think the general consensus is that ffs can be inconsistent it ways
> > > > fsck is unable to detect.
> > >
> > > ...much less fix. Yes. When I was doing the program that eventually
> > > got massaged into resize_ffs, during development I had some filesystems
> > > that were definitely corrupted but that fsck was happy with. (I rather
> > > wish I'd saved some of them as test cases, but I didn't.)
>
>I also once after abusing rename got a filesystem where fsck -y didn't
>converge; I had to newfs it.
>
> > Sounds like there is an in interesting fuzzing project in there for
> > someone - make a filesystem mage and the repeatedly damage it, then
> > see if fsck can fix it, then if you get a rump panic when moving
> > everything around, and then re-run fsck to see if it indicates any new
> > issues :)
>
>One can do that, but given that there are lots of edge cases and many
>of them will be hard to reach, formal verification might be more
>effective.
>
I think we should fix all filesystems to pass:
https://www.netbsd.org/~riastradh/tmp/dirconc.c
Then we can think about formal verification :-)
christos
