svn commit: r334970 - head

[Warner Losh]

On Mon, Jun 11, 2018 at 2:01 PM, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> [ Charset UTF-8 unsupported, converting... ]
> > On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
> > freebsd at pdx.rh.cn85.dnsmgr.net> wrote:
> >
> > > [ Charset UTF-8 unsupported, converting... ]
> > > > Author: imp
> > > > Date: Mon Jun 11 19:32:40 2018
> > > > New Revision: 334970
> > > > URL: https://svnweb.freebsd.org/changeset/base/334970
> > > >
> > > > Log:
> > > >   Document the dump issue in UPDATING so people understand when they
> > > >   get a new diagnostic.
> > > >
> > > > Modified:
> > > >   head/UPDATING
> > > >
> > > > Modified: head/UPDATING
> > > > ============================================================
> > > ==================
> > > > --- head/UPDATING     Mon Jun 11 19:32:36 2018        (r334969)
> > > > +++ head/UPDATING     Mon Jun 11 19:32:40 2018        (r334970)
> > > > @@ -32,6 +32,13 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 12.x IS
> SLOW:
> > > >       "ln -s 'abort:false,junk:false' /etc/malloc.conf".)
> > > >
> > > >
> > > > +20180611:
> > > > +     A bug in dump has been found where it can incorrectly dump
> > > filesystems
> > > > +     with more than 512k inodes and produce corrupted dump images.
> > > r334968
> > > > +     closes the door by not dumping filesystems with more than 512k
> > > inodes.
> > > > +     While older dumps may 'work' the image they produce may or may
> not
> > > be
> > > > +     readable depending on many factors.
> > > > +
> > >
> > > Does it make since to put a temporary warning in newfs to warn users
> > > of the "may bot be able to dump this fs" issue?
> > >
> >
> > It does.
> >
> > However, there may have been an error in assessment, which I'm working
> > through now. If so, there will be a revert.
>
> Ok, I am wondering some about this as I have:
> Filesystem               1024-blocks      Used     Avail Capacity iused
>  ifree %iused  Mounted on
> /dev/ada0s2h               473659989 417657089  18110101    96%  918794
> 47949908    2%   /mnt
>
> And have had that file system for at least a decade,
> and it gets dump | restore on a fairly regular basis.


Yea. Are you in a good position to test a fix for the core dump db@ was
seeing? A dump /restore (though the restore should be to a second fs to
test)

There's two things my fix does: (1) backs out the mistaken limit check and
(2) doesn't walk through a list that's guaranteed to be bogus and fall off
the end.

Warner