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 00:52:00 +0100
Markus W Kilbinger <> wrote:

> >>>>> "Sarton" == Sarton O'Brien <> 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,

Home | Main Index | Thread Index | Old Index