Re: In-kernel units for block numbers, etc ...

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 29 Nov 2015 00:05:37 +0000 (UTC)
    From:        mlelstv%serpens.de@localhost (Michael van Elst)
    Message-ID:  <n3dfgg$p6g$1%serpens.de@localhost>

  | It doesn't need to, the backend is a file and you can access arbitrary
  | byte positions.

You would think so, and that is probably what should happen, but I just
did a test, and it doesn't work...

I think it is the same underlying problem that used to prevent vnd's
being backed by files with holes.

The vnd driver is (from what I can tell from skimming it) trying to be
smart - if it can (if it thinks it can) it bypasses the generic file i/o
and goes directly to the underlying device's, what a comment at the start
of vnd.c says is ...

 * NOTE 1: If the vnode supports the VOP_BMAP and VOP_STRATEGY operations,
 * this uses them to avoid distorting the local buffer cache.  If those
 * block-level operations are not available, this falls back to the regular
 * read and write calls.

It turns out it also "falls back" if it deduces that the underlying file
has holes.   The "falls back" is when the (internal) VNF_USE_VN_RDWR
is set.

To verify this, I made 3 files with dd, two identical (just lots of blocks
from /dev/zero) and the third, identical as a file, but full of hole
(just one final 64k segment from /dev/zero, the rest skipped with oseek=)

I ran vnconfig on all three, one of the unholy files, with 4k sectors
(on the vndconfig command line geometry spec), the other two with 512
byte sectors.

vndconfig worked (or reported no errors) in all cases.   The 512 byte
sector on the unholy file produces a bizarre default disklabel though,
with all 16 possible partitions in use, each of them (aside from d)
being identical (start 0, full size, 4.2BSD type).   The disklabel
command insisted on telling me about every pair of overlapping partitions...

The other two produces "normal" labels (a and d partitions only).

newfs /dev/vndNa
(no other options) on the three of them ... the 4k sector, and holy 512
byte sector worked fine, the 512 byte sector unholy file gave EINVAL
attempting to write at the end of the "disk", and exited very quickly.

On the 512 byte sector unholy drive, I also tried a "dd"

	dd if=/dev/zero of=/dev/rvnd1a bs=512 count=8 oseek=200

(or something similar to that .. writing 512 bytes at a time, for some
small number of sectors, starting into the drive beyond the label).
That also gave EINVAL on the first attempted write.

Hence, I believe you are mistaken, it is currently not possible to
emulate a smaller sector disk on a file on a larger sector drive.
Exactly what the restrictions are I haven't attempted to work out
(whether it is just what the hardware can support, or whether the
emulated sector size gets related to the file system block, or frag,
sizes or something).   But there is definitely some restriction there.

If someone can work out what the requirement is, and can write code to
test for it, fixing this will be easy - it just needs an appropriate
(additional) test to set the VNF_USE_VN_RDWR flag in the vnd sc_flags.

kre