Re: strange vnd disk behavior in -current (with ffs2?)

[Markus W Kilbinger <mk%kilbi.de@localhost>]

>>>>> "Steven" == Steven M Bellovin <smb%cs.columbia.edu@localhost> writes:

    >> >>> dd if=/dev/zero of=temp.disk bs=1 seek=100000000 count=1

    Sarton> Just to clarify, I think he meant sparse disk image. This
    Sarton> has been a problem/feature of vnd for some time. Try a
    Sarton> larger block size/count and no seek.

    >> - It takes a lot of time which I tried to avoid ;-)
    >> 
    >> - What happens to the 'seek=100000000' space/gap in my dd
    >>   example? Shouldn't it be some kind of pre-allocated and
    >>   really allocated when it's accessed?

    Steven> No -- that's precisely what a sparse file is, and it's
    Steven> been Unix behavior since the Epoch, I believe... 'ls -s'
    Steven> shows it clearly:

Hmm, what does a program 'see' if it opens such a sparse file and
tries to read a sparse region out of it? An error message? Zero-d /
random data without a read error?

    Steven> Now -- it's certainly a limitation of vnd that it can't
    Steven> handle sparse files, and a panic is the wrong way for this
    Steven> to be detected, but the bottom line is that what you did
    Steven> is not expected to work on NetBSD.

Ok, if it's really a limitation of vnd(4) then how to ensure that it
does not run into this sparse file problem? Should vnconfig(8) check
for sparse files? Just to rely on users care seems not to be
sufficient (in my case ;-))...

BTW: Thanks for all of your explanation!

Markus.