Re: bin/45933: fsck_ffs can't find wapbl journal on 4k-block disks

[David Krinsky <krinsky%bantha.org@localhost>]

The following reply was made to PR bin/45933; it has been noted by GNATS.

From: David Krinsky <krinsky%bantha.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: mlelstv%NetBSD.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 
(mlelstv%serpens.de@localhost) wrote:
 >  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.
 
 Michael,
 
 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
 journal.  
 
 David