[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 <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?
> 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
Main Index |
Thread Index |