newfs returns cg 0: bad magic number
Willem Jan Withagen
wjw at digiware.nl
Fri Jul 7 21:16:28 UTC 2017
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
More information about the freebsd-fs
mailing list