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

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

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

> >>>>> "Sarton" == Sarton O'Brien <bsd-xen%roguewrt.org@localhost> writes:
> 
>     Sarton> Adam Hamsik wrote:
>     >> Hi, On Oct,Thursday 30 2008, at 11:09 PM, Markus W Kilbinger
>     >> wrote:
>     >>> 
>     >>> dd if=/dev/zero of=temp.disk bs=1 seek=100000000 count=1
>     >> 
>     >> You are creating spare disk image here don't you ? AFAIK vnd
>     >> doesnt support spare images for now.
> 
>     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.
> 
> Ok, that would be the clean way, but:
> 
> - 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?

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

y129$ dd if=/dev/zero of=temp.disk bs=1 seek=100000000 count=1
1+0 records in
1+0 records out
1 bytes transferred in 0.001 secs (1000 bytes/sec)
y130$ ls -l temp.disk
-rw-r--r--  1 smb  wheel  100000001 Oct 30 20:03 temp.disk
y131$ ls -s temp.disk
48 temp.disk

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

> 
> - The reaction to my fdisk's usage is (at least) inadequate. An error
>   message would be more helpful (instead of a kernel panic or just
>   doing nothing). If it's a vnd(4) limitation it should be at least
>   documented.
> 
> Markus.
> 



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