Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

On Fri, 31 Oct 2008 07:22:04 +0100
Markus W Kilbinger <> wrote:

> >>>>> "Steven" == Steven M Bellovin <> 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 ;-))...
I'll leave that to someone else.

                --Steve Bellovin,

Home | Main Index | Thread Index | Old Index