On Fri, 26 Jul 2002, Greg Oster wrote:

> A colleague of mine was having trouble copying files from a CD ISO that
> was mounted using the vnd device.  To make a longer story short,
> investigation has revealed the following:
>
> In vnd.c, vnd->sc_size is set initially as:
>
> 		vnd->sc_size = btodb(vattr.va_size);	/* note truncation */

Makes sense, we are a block-based device, we can't read parts of a block.

> but then the lines:
>
> 			vnd->sc_geom.vng_ncylinders = vnd->sc_size / (64 * 32);
>
> 			/*
> 			 * Compute the actual size allowed by this geometry.
> 			 */
> 			geomsize = 32 * 64 * vnd->sc_geom.vng_ncylinders;
>
> in vnd.c compute a 'geomsize' value that is smaller than the size of
> the image (unless the size of the image falls on a 1MB boundary).  When
> 'geomsize' is then assigned to 'vnd->sc_size' in the following:
>
> 		/*
> 		 * Truncate the size to that specified by
> 		 * the geometry.
> 		 * XXX Should we even bother with this?
> 		 */
> 		vnd->sc_size = geomsize;
>
> vnd->sc_size is now smaller than it was before, and the last part of the image
> (up to 1MB) ends up being inaccessible through the vnd.  For example, an iso
> image of 680624128 bytes (664672K) should have it's disklabel size computed
> to be 1329344 blocks, whereas right now, that size is computed to be just 1329152.
> ( (664672*2)/(32*64)=649.09375 , and then 649*32*64=1329152 ).
>
> The fix (from what I and others have concluded) is to remove the line:
>
>                 vnd->sc_size = geomsize;
>
> since this would leave the size of the vnd at 1329344 blocks, and the
> disklabel would still have a reasonable geometry.

Sounds good. We have to deal with real disks whose size != the geometry
size, so I don't see why vnd needs this special treatment.

Other thoughts?

Take care,

Bill