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

[Michael van Elst <mlelstv%serpens.de@localhost>]

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

From: Michael van Elst <mlelstv%serpens.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/45933: fsck_ffs can't find wapbl journal on 4k-block disks
Date: Sun, 13 Jul 2014 11:41:25 +0200

 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.
 
 (*) 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.
 
 This is fine, unless you try to access the filesystem from the Dom0
 which obviously knows that the disk sectors are larger. The
 superblock no longer matches reality and fsck does the wrong thing.
 
 Something similar happens when you copy a FFS image between disks with
 different sector sizes.
 
 
 
 
 Greetings,
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."