Re: vnd geometry

[Patrick Welche <prlw1%cam.ac.uk@localhost>]

On Tue, Apr 29, 2014 at 04:44:52PM +0100, Patrick Welche wrote:
> On Tue, Apr 29, 2014 at 04:08:02PM +0200, J. Hannken-Illjes wrote:
> > On 29 Apr 2014, at 15:19, Patrick Welche <prlw1%cam.ac.uk@localhost> wrote:
> > 
> > <snip>
> > > 
> > > One oddity while perusing the code is:
> > > 
> > >        /*
> > >         * Use pseudo-geometry specified.  If none was provided,
> > >         * use "standard" Adaptec fictitious geometry.
> > >         */
> > >        if (vio->vnd_flags & VNDIOF_HASGEOM) {
> > > 
> > >            memcpy(&vnd->sc_geom, &vio->vnd_geom,
> > >                sizeof(vio->vnd_geom));
> > > 
> > > How can VNDIOF_HASGEOM ever be set?
> > 
> > With <geomspec> from vnconfig(8)?
> 
> Ah thanks - I just used fxr.watson.org...
> 
> It seems that disklabel and plist agree at least for sizes which are
> whole numbers of megabytes, e.g.,
> 
> bytes:
> disklabel        plist backing_file
>  10485760     10485760     10485760  =  A00000 
> 136314880    136314880    136314880  = 8200000
>  12761600     12582912     12761760 (this row in hex below)
>    C2BA00       C00000       C2BAA0

plist gets its idea of size by multiplying nsectors*ntracks*ncylinders.
disklabel gets its idea of size by rounding down the backing file size
to the nearest number of disk blocks.

I am tempted to set plist's idea to sc_size as per the disklabel.
If I were to do that, I suspect I would break HASGEOM?

OK to change struct vndgeom to add a vng_size member and set it as
appropriate according to HASGEOM? But then VNDIOC{SET,CLR}50 would
break?

Thoughts?

Cheers,

Patrick