[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: David Krinsky <krinsky%bantha.org@localhost>
Subject: Re: bin/45933: fsck_ffs can't find wapbl journal on 4k-block disks
Date: Sun, 13 Jul 2014 08:53:02 -0400
On Sun, Jul 13, 2014 at 09:45:00AM +0000, Michael van Elst
> The code really does the right thing because the superblock stores the
> journal position in physical block numbers(*).
> The WAPBL code in the kernel then translates to 512byte block numbers
> because that's what all disk drivers in NetBSD expect. The disk driver
> (e.g. scsipi) then translates back to physical block numbers.
> In Userland the physical block number is translated by
> wapbl_read/wapbl_write to a byte offset by multiplying it with
> the physical sector size and the byte offset is used to seek
> the device or image.
Thank you for the response. But if this is the full explanation, why
does fsck in the domU fail? That is what I am seeing-- this bug
doesn't depend on creating a filesystem in a domU and then fscking it
from dom0. My problem--which I run into in the field any time one of
my domUs crashes--is that fsck in the *domU* fails.
> (*) So why does your superblock seem to have a logical block
> number for the journal position?
> The reason is Xen, the xen driver presents the virtual disk as a
> 512byte/sector device independently of the underlying hardware.
> Therefore the DomU thinks it talks to such a device, and will write
> a journal position measured in 512byte blocks. fsck on the DomU
> also works because it uses the same geometry.
It isn't working in my case--the wapbl code called by fsck in the domU
is incorrectly treating the journal position as though it were in 4K
blocks, doing the conversion, and fsck in the domU fails to find the
Main Index |
Thread Index |