From owner-freebsd-current@freebsd.org Sat Jul 8 16:28:51 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28756D9D6C5 for ; Sat, 8 Jul 2017 16:28:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E4649211 for ; Sat, 8 Jul 2017 16:28:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id v68GSfbJ068203; Sat, 8 Jul 2017 09:28:41 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id v68GSd0i068202; Sat, 8 Jul 2017 09:28:39 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201707081628.v68GSd0i068202@pdx.rh.CN85.dnsmgr.net> Subject: Re: dump trying to access incorrect block numbers? In-Reply-To: To: Michael Butler Date: Sat, 8 Jul 2017 09:28:39 -0700 (PDT) CC: Peter Jeremy , freebsd-current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Sat, 08 Jul 2017 16:39:01 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jul 2017 16:28:51 -0000 > On 07/07/17 21:53, Peter Jeremy wrote: > > On 2017-Jul-07 10:44:36 -0400, Michael Butler wrote: > >> Recent builds doing a backup (dump) cause nonsensical errors in syslog: > > > > I can't directly offer any ideas but some more background might help: > > When did you first notice this (what SVN revision)? > > I was stuck on SVN r319721 on the i386 machine while the socket/union > issue was addressed. That version did not display the problem. > > > Do you know what the last good SVN revision was? > > Is this a new or old filesystem? > > old - it's been years since this system was rebuilt. > > > Is the filesystem mounted/active or not when you dump it? > > Mounted and active. > > > What are the relevant parameters for the filesystem on ada0s3a? > > imb@toshi:/home/imb> dumpfs / > > magic 19540119 (UFS2) time Fri Jul 7 22:43:49 2017 > superblock location 65536 id [ 56c8bf68 1a8b12b5 ] > ncg 516 size 82575360 blocks 79978821 > bsize 32768 shift 15 mask 0xffff8000 > fsize 4096 shift 12 mask 0xfffff000 > frag 8 shift 3 fsbtodb 3 > minfree 8% optim time symlinklen 120 > maxbsize 32768 maxbpg 4096 maxcontig 4 contigsumsize 4 > nbfree 3965346 ndir 98169 nifree 40196026 nffree 453383 > bpg 20035 fpg 160280 ipg 80256 unrefs 0 > nindir 4096 inopb 128 maxfilesize 2252349704110079 > sbsize 4096 cgsize 32768 csaddr 5056 cssize 12288 > sblkno 24 cblkno 32 iblkno 40 dblkno 5056 > cgrotor 253 fmod 0 ronly 0 clean 0 > metaspace 6408 avgfpdir 64 avgfilesize 16384 > flags soft-updates > fsmnt / > volname swuid 0 providersize 82575360 > > [ .. ] > > > Are you running softupdates, journalling etc? > > soft-updates only. > > > Which dump(8) phase is reporting the errors? > > The errors occur before the "date of the last level x dump" message - > presumably, this is while creating the snapshot. > > > What are the exact dump and fsck commands you ran? > > /sbin/dump 0Lauf - -C 32 / > > none of the following report any (unexpected) errors: > > fsck -f / > fsck -f -r / > fsck -f -Z / > > > > >> I now have two UFS-based systems showing the same symptoms - what's up > >> with this? > > > > Was there anything you did on either filesystem that might have triggered it? > > Other than update the kernel, no. Since it has been speculated that this is occuring during the creation of the snapshot, could you try just creating a snapshot using mksnap_ffs and see if any errors occur? -- Rod Grimes rgrimes@freebsd.org