Date: Fri, 7 Jul 2017 23:16:17 +0200 From: Willem Jan Withagen <wjw@digiware.nl> To: Bruce Evans <brde@optusnet.com.au>, Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: newfs returns cg 0: bad magic number Message-ID: <9dd06699-a98b-2c8b-e710-73372b55c5d2@digiware.nl> In-Reply-To: <20170707220108.F1124@besplex.bde.org> References: <c98c813c-c393-9ba5-5c70-b9575fe59553@digiware.nl> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9dd06699-a98b-2c8b-e710-73372b55c5d2>