[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/45933: fsck_ffs can't find wapbl journal on 4k-block disks
The following reply was made to PR bin/45933; it has been noted by GNATS.
From: Michael van Elst <mlelstv%serpens.de@localhost>
To: David Krinsky <krinsky%bantha.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, mlelstv%NetBSD.org@localhost,
Subject: Re: bin/45933: fsck_ffs can't find wapbl journal on 4k-block disks
Date: Tue, 15 Jul 2014 06:33:58 +0200
On Sun, Jul 13, 2014 at 06:38:51PM -0400, David Krinsky wrote:
> # dumpfs -s /dev/xbd4
> wapbl version 0x1 location 1 flags 0x0
> wapbl loc0 268435456 loc1 131072 loc2 512 loc3 0
location = 1 UFS_WAPBL_JOURNALLOC_END_PARTITION
loc0 = 268435456 Journal placed at this physical offset
loc1 = 131072 Journal size is 128k sectors.
loc2 = 512 Physical sector size 512 bytes.
So WAPBL says it uses 512 byte sectors.
> # drvctl -p xbd4
The disk driver also reports 512 byte sectors.
However, fsck uses this value only to find the superblock and does
a recalculation of the sector size based on the superblock contents,
so that it can support filesystem images.
dev_bsize = sblock->fs_fsize / FFS_FSBTODB(sblock, 1);
> fsize 4096 shift 12 mask 0xfffff000
> frag 8 shift 3 fsbtodb 0
this evaluates to:
4096 / (1 << 0)
The problem is that the fsbtodb value in the superblock is wrong.
The value holds the shift value between filesystem block size
(which is really the fragsize not the blocksize!) and
the physical sector size. So the superblock says the physical
sector size is 4096.
Did you create the filesystem with newfs -S 4096 or on the Dom0 ?
That would explain why the superblock has the wrong value.
Kernel code works because it ignores the fsbtodb value. It also
created the journal at the first mount and stored its location
based on the actual driver values.
Michael van Elst
"A potential Snark may lurk in every tree."
Main Index |
Thread Index |