Re: CVS commit: src/sys/dev

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sat, Jun 14, 2008 at 11:44:57AM +0000, Christoph Egger wrote:
> 
> Module Name:  src
> Committed By: cegger
> Date:         Sat Jun 14 11:44:57 UTC 2008
> 
> Modified Files:
>       src/sys/dev: vnd.c
> 
> Log Message:
> Checking if the underlying file system supports VOP_BMAP and VOP_STRATEGY 
> does not imply that works.
> Test if VOP_BMAP actually works before using bmap/strategy.
> 
> When you create an image with
> 
> dd if=/dev/zero of=./netbsd.img bs=1m count=1 seek=1000

So you create a sparse file. Note that this has never been officially
supported for vnd writes (and so for xen read/write backend).

> 
> then the current check actually determines the "file system"
> in the image supports VOP_BMAP and VOP_STRATEGY, but VOP_BMAP can't
> translate any logical block numbers which results in EIO failures.
> 
> When you try to access the image in a Xen DomU you see all disk operations
> failing. Therefore test if VOP_BMAP actually works and fall back to
> VOP_READ/VOP_WRITE if it doesn't.
> 
> This makes a Xen DomU installation working.

the domU write to its filesystem will allocate the needed blocks in the
sparse file. But the file is still sparse.

> When you boot your fresh
> installed Xen DomU with a valid disklabel and file system in the image,
> VOP_BMAP actually works and is used.

VOP_BMAP will still fail if it hits a non-allocated block. If you mount
the domU filesystem read/write (or of the xbd holds a swap partition),
writes are likely to fail, unless they hit an already-used place.

I think this change doesn't make sparce file work reliably for
Xen domUs. If you want this to work, you either have to
always use VOP_READ/VOP_WRITE when possible, or have use a more reliable way
to check if the file is sparse (e.g. checking the number of allocated
blocks against the size of the file).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--