Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Jun 2018 14:23:20 -0700 (PDT)
From:      "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net>
To:        Warner Losh <imp@bsdimp.com>
Cc:        "Rodney W. Grimes" <rgrimes@freebsd.org>, Warner Losh <imp@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r334970 - head
Message-ID:  <201806112123.w5BLNKE6030094@pdx.rh.CN85.dnsmgr.net>
In-Reply-To: <CANCZdfoPu%2B1OFGfiUkcBcfk=LrL1MTyz6wZSJKN4Ovd80Xnq1w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
> On Mon, Jun 11, 2018 at 2:01 PM, Rodney W. Grimes <
> freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
> 
> > [ Charset UTF-8 unsupported, converting... ]
> > > On Mon, Jun 11, 2018 at 1:52 PM, Rodney W. Grimes <
> > > freebsd@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)

Yes, I have 4 spare drives that can be used as restore targets of
the above mentioned file system.  And actually have at least 2
copies of it already for sources, so it is just a mater of minutes
for me to set up a test bed.

> 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

-- 
Rod Grimes                                                 rgrimes@freebsd.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201806112123.w5BLNKE6030094>