[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 <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
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
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Main Index |
Thread Index |