From owner-freebsd-current@freebsd.org Sat Jul 8 00:02:38 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 682F9DADCD3 for ; Sat, 8 Jul 2017 00:02:38 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-33.reflexion.net [208.70.210.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 181BC6785F for ; Sat, 8 Jul 2017 00:02:37 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 571 invoked from network); 8 Jul 2017 00:02:36 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 8 Jul 2017 00:02:36 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 07 Jul 2017 20:02:36 -0400 (EDT) Received: (qmail 2271 invoked from network); 8 Jul 2017 00:02:26 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 8 Jul 2017 00:02:26 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1C43CEC9379; Fri, 7 Jul 2017 17:02:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: dump trying to access incorrect block numbers? [It is not just dump that can get such] From: Mark Millard In-Reply-To: Date: Fri, 7 Jul 2017 17:02:25 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Butler X-Mailer: Apple Mail (2.3273) 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 00:02:38 -0000 On 2017-Jul-7, at 4:49 PM, Michael Butler wrote: > On 07/07/17 19:02, Mark Millard wrote: >> Michael Butler imb at protected-networks.net wrote on >> Fri Jul 7 14:45:12 UTC 2017 : >>> Recent builds doing a backup (dump) cause nonsensical errors in = syslog: >>>=20 >>> Jul 7 00:10:24 toshi kernel: >>> g_vfs_done():ada0s3a[READ(offset=3D6050375794688, = length=3D32768)]error =3D 5 >>> Jul 7 00:10:24 toshi kernel: >>> g_vfs_done():ada0s3a[READ(offset=3D546222112768, length=3D32768)]error= =3D 5 >>> Jul 7 00:10:24 toshi kernel: >=20 > [ snip ] >=20 >> Both dump and fsck likely are using snapshots >> so the issue is likely ties to ufs snapshots. >> May be it has a INO64 incompleteness that >> gives the huge offsets. (Wild guess.) >> If your context was more typical then the issue >> spans little-endian and big-endian since the >> powerpc context is big-endian but most usage >> is little endian. >=20 > I'm seeing this on both amd64 and i386 builds (@SVN r320760) when dump = tries to build a snap-shot. These are both non-debug, non-invariant = production boxes Sounds like there is enough evidence of repeatability, span of TARGET_ARCH's and systems, and recent enough range of -r320??? vintages for a bugzilla submittal. Your TARGET_ARCH's are more main-stream then where I've tried something that showed the issue. What to do the initial submittal? =3D=3D=3D Mark Millard markmi at dsl-only.net