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

["Steven M. Bellovin" <smb%cs.columbia.edu@localhost>]

On Fri, 31 Oct 2008 07:22:04 +0100
Markus W Kilbinger <mk%kilbi.de@localhost> wrote:

> >>>>> "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?

Zeros.
> 
>     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 ;-))...
> 
I'll leave that to someone else.


                --Steve Bellovin, http://www.cs.columbia.edu/~smb