From owner-freebsd-fs@freebsd.org Fri Jul 7 21:16:28 2017 Return-Path: Delivered-To: freebsd-fs@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 A4255DAB90E for ; Fri, 7 Jul 2017 21:16:28 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (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 524D23822 for ; Fri, 7 Jul 2017 21:16:27 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 1D8F144738; Fri, 7 Jul 2017 23:16:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHWh7BxxA6qt; Fri, 7 Jul 2017 23:16:18 +0200 (CEST) Received: from [192.168.10.67] (opteron [192.168.10.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 31B0044737; Fri, 7 Jul 2017 23:16:18 +0200 (CEST) Subject: Re: newfs returns cg 0: bad magic number To: Bruce Evans , Konstantin Belousov Cc: FreeBSD Filesystems References: <20170705051458.GU1935@kib.kiev.ua> <20170705154533.M1171@besplex.bde.org> <9fe3ec97-60ea-e9e6-fb65-9b163d64ac45@digiware.nl> <20170707062354.GP1935@kib.kiev.ua> <20170707220108.F1124@besplex.bde.org> From: Willem Jan Withagen Message-ID: <9dd06699-a98b-2c8b-e710-73372b55c5d2@digiware.nl> Date: Fri, 7 Jul 2017 23:16:17 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170707220108.F1124@besplex.bde.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jul 2017 21:16:28 -0000 On 7-7-2017 16:23, Bruce Evans wrote: > On Fri, 7 Jul 2017, Konstantin Belousov wrote: Reverted all I changed and, I have the following change now that diagnose the errors, against 11.1RC1: for mkfs.c: 532,533c533,534 < if (!Nflag) < do_sbwrite(&disk); --- > if (!Nflag && do_sbwrite(&disk) == -1) > err(1, "do_sbwrite(%d): ", __LINE__ ); 601c602,603 < do_sbwrite(&disk); --- > if (do_sbwrite(&disk) == -1) > err(1, "do_sbwrite(%d): ", __LINE__ ); But that brings me back to the original issue: cg 0: bad magic number > For newfs, there are a lot of silly complications involving the block size: > - the of initialization of disk.d_bsize to sectorsize (from the firmware > or label) or even the -S option doesn't seem to be good for anything. > Actually, the comment explains this. It says that "Our blocks = sector > size". This is not what libufs wants. It is what was convenient for > newfs before libufs. It sometimes works for libufs too, but is not > documented to work (no method for initializing disk.d_bsize is > documented). > - oops, the wrapper db_sbwrite() is no to handle complications for the > block > size. It is to add the partition offset. For most i/o's newfs tells > libufs the full offset. Superblock i/o's are special because the offsets > are passed implicitly and the implicit values don't contain the offset. # newfs /dev/ggate0 /dev/ggate0: 64.0MB (131072 sectors) block size 32768, fragment size 4096 using 4 cylinder groups of 16.03MB, 513 blks, 2176 inodes. super-block backups (for fsck_ffs -b #) at: 192, 33024, 65856, 98688 cg 0: bad magic number But the geom access pattern is rather akward: 1) ggate0[WRITE(offset=67108352, length=512)] 2) ggate0[READ(offset=8192, length=8192)] 3) ggate0[WRITE(offset=65536, length=8192)] 4) ggate0[WRITE(offset=98304, length=131072)] 5) ggate0[WRITE(offset=16908288, length=131072)] 6) ggate0[WRITE(offset=33718272, length=131072)] 7) ggate0[WRITE(offset=50528256, length=131072)] 8) ggate0[READ(offset=131072, length=4096)] WRITE-4 is where initcg writes the first cylinder group. So there should cg_magic be set. READ-8 is the bread that actually errors in not reading CG_MAGIC. mkfs.c:1002:alloc(): bread(&disk, part_ofs + fsbtodb(&sblock, cgtod(&sblock, 0)), (char *)&acg, sblock.fs_cgsize) This data was written in WRITE-4. The full disk.d_cg seems to be empty both in the acg block as well as on disk: # hexdump -s 128k /dev/ggate0 0020000 0000 0000 0000 0000 0000 0000 0000 0000 * 0024880 0000 0000 0255 0009 0000 0000 0003 0000 the second cg however does seem the have a correct CG_MAGIC in the second 32bit var (0x90255) on line 24880. So I'm assuming that it did not get written. Now things are even more awkward, in that once in a while newfs does complete without complaints. Making me believe that some uninitialized use could play a role --WjW