From owner-freebsd-current@freebsd.org Fri Jul 7 23:02:55 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 248CBDAD037 for ; Fri, 7 Jul 2017 23:02:55 +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 CD50D66123 for ; Fri, 7 Jul 2017 23:02:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25781 invoked from network); 7 Jul 2017 23:04:25 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 7 Jul 2017 23:04:25 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Fri, 07 Jul 2017 19:02:52 -0400 (EDT) Received: (qmail 15748 invoked from network); 7 Jul 2017 23:02:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 7 Jul 2017 23:02:52 -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 A64ADEC942D; Fri, 7 Jul 2017 16:02:51 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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] Message-Id: Date: Fri, 7 Jul 2017 16:02:51 -0700 To: imb@protected-networks.net, FreeBSD Current 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: Fri, 07 Jul 2017 23:02:55 -0000 Michael Butler imb at protected-networks.net wrote on=20 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:=20 > g_vfs_done():ada0s3a[READ(offset=3D6050375794688, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D546222112768, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D2142846844928, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi last message repeated 7 times > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D2226879725568, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D2941159211008, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi last message repeated 2 times > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D3067208531968, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D3277290733568, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D3487372935168, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D3697455136768, length=3D32768)]error = =3D 5 > Jul 7 00:10:24 toshi kernel:=20 > g_vfs_done():ada0s3a[READ(offset=3D3865520898048, length=3D32768)]error = =3D 5 >=20 > FSCK declares nothing to be wrong with the file-system. I even used = the=20 > '-r' inode reclaim option and '-Z' to zero unused blocks to no effect. >=20 > I now have two UFS-based systems showing the same symptoms - what's up=20= > with this? I've seen these kind of messages on 32-bit powerpc -r320570 when using "boot -s" (standalone) and doing an fsck after making the ufs root file system writable. (-r320570 could not boot multi-user all the way without workarounds due to socket software errors.) [Context was a production-style kernel build, not the debug style --but I likely did not try this for a debug kernel build.] The messages came out before the following: (manually retyped from a camera picture) ** //.snap/fsck_snapshot ** Last Mount on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups Reclaimed: 0 directories, 1 files, 22680 fragments 780914 files, 4797127 used, 19552199 free (443479 frags, 3288590 blocks, = 1.8% fragmentation) ***** FILE SYSTEM MARKED CLEAN ***** There were a lot of the messages. I've not checked if anything after -r320570 for 32-bit powerpc shows such or not. (The socket software problem has an official fix checked in: -r320652 . But I've not got as far as progressing to it or beyond yet.) -r320570 was a fix of another major problem for the use of __pthread_cleanup_push_imp stubs. I was not sure if the g_vfs_done notices were a distinct issue from the other issues of the time frame or not at the time and did not get as far as investigating that question at the time. 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. =3D=3D=3D Mark Millard markmi at dsl-only.net