On 29 Apr 2014, at 18:23, Patrick Welche <pr...@cam.ac.uk> wrote: > 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 <pr...@cam.ac.uk> 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?
In vnd_set_geometry(): - dg->dg_secperunit = (int64_t)vnd->sc_geom.vng_nsectors * - vnd->sc_geom.vng_ntracks * vnd->sc_geom.vng_ncylinders; + dg->dg_secperunit = vnd->sc_size; (completely untested of course ..) -- J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)