From owner-freebsd-fs@freebsd.org Sat Jul 8 00:13:01 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 20646DADF82 for ; Sat, 8 Jul 2017 00:13:01 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA5B567C91 for ; Sat, 8 Jul 2017 00:13:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x244.google.com with SMTP id z62so589422ioi.0 for ; Fri, 07 Jul 2017 17:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5oagBlLjzTiAuZvmd6kDa1FiS2ChdocWLumj0cHVGmg=; b=D9YoudGOBWGEhjkTwSLNKD2rDgdefVwdTbAaJtqiqzlQCb4uFFzSb3aFv+xyHaIywF ZFvULZCoyAH4tRZGDhAFOgm9R5l0vvAO7e0hvsxKxxzSIHz+llp76aPMJm9fncJXoaQw YdN9/KRQqt5eXFdhVA7XFlWeyOCBOfR/2ocpBA5VApZBDioi2nYin99Knd8aBITtfgkv E7G4uG4naGbZb8XDzA25skpP5QkGd8U08LfCXRwkHL0ZrX5fA5kQqZR4AZARXeDELHzZ rFhpGsOwpLPwRLnf3QTMLw0oDzLk5tJQKzb+eshweijnKN2ejc1ji9vgBVpsPhv2x7Ej 6dYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5oagBlLjzTiAuZvmd6kDa1FiS2ChdocWLumj0cHVGmg=; b=nFdALchZ7JtEb7BCIgN8hnRVaOF+QWNDJggVjYuuZzGMLWPBznVWm4fz4tzAL1+u3P no3xb1jUahPtDFUVFnXL3cAGNJvM3wWmLEF1WEIwlhwOI2GUCS+aewZ+SlWdpAEQUYnB tix3sGDvsf7FfkBqOvraQ7JlpjanRnIYLTzynP/2yOcl8Dq0gDRikrX2CC54lMzAHEoB O8vBHTy2yW/LD7qXK1wNLZkmSZ1PHauo+D3dZ6W6uz+EJ0Fw3ZGm+OyN+AnT/lrQqKDs h+vzJxSa9obV1W1xU/6H2JAxtNemTSkm+rIKLpiwz8xJIG5mteZA2snp3yHnCm8DMpDa BHfA== X-Gm-Message-State: AKS2vOz7G7zs6ibL7lOwm/9Ir6cMA4QlFy+JERotXAI+VcDK04BHq7RQ UeGhYqsm9joLBFBO7ug9rwRLaXwkDhJR X-Received: by 10.107.178.13 with SMTP id b13mr64400672iof.148.1499472779849; Fri, 07 Jul 2017 17:12:59 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.212.167 with HTTP; Fri, 7 Jul 2017 17:12:59 -0700 (PDT) X-Originating-IP: [2607:fb90:6e26:c4a6:0:4e:8014:5301] Received: by 10.79.212.167 with HTTP; Fri, 7 Jul 2017 17:12:59 -0700 (PDT) In-Reply-To: <9dd06699-a98b-2c8b-e710-73372b55c5d2@digiware.nl> 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> <9dd06699-a98b-2c8b-e710-73372b55c5d2@digiware.nl> From: Warner Losh Date: Fri, 7 Jul 2017 18:12:59 -0600 X-Google-Sender-Auth: GRSBzaod2VSWbwtj_n2ytGzyyCU Message-ID: Subject: Re: newfs returns cg 0: bad magic number To: Willem Jan Withagen Cc: Bruce Evans , FreeBSD FS , Konstantin Belousov Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Sat, 08 Jul 2017 00:13:01 -0000 On Jul 7, 2017 3:16 PM, "Willem Jan Withagen" wrote: 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 We are seeing at work corruption where we newfs and create a bunch of directories and reboot. On the fsck, it complains that the two sup er blocks don't match and 15 of the 256 directories we created return EBADF when listed. It looks like some of the writes didn't reach disk maybe. We are chasing it down still. This is with current of maybe 4-8 weeks ago... Warner --WjW _______________________________________________ freebsd-fs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"