Jason Lash wrote:
I created the disk without zeroing via the instructions in the
'Installing in Xen' guide from the Plan9 wiki
(http://www.cs.bell-labs.com/wiki/plan9/Installing_in_Xen/). If this
is reproducable, it might be worth an update to the guide.
I used the following originally (copied from the guide):
dd if=/dev/zero of=plan9.img seek=$((1024 * 1024 * 1024 - 1)) bs=1 count=1
It just zero's the last bit and allocates the rest as-is. Its instant,
which is nice, but obviously gave me a garbage mbr and partition
table.
that's not it. What that dd does is what this perl script does, I think:
# make it look like C argv[]
unshift(@ARGV, "XX");
$size=1024*1024*1024*4;
$file = "file.out";
if ($#ARGV > 1) { $size = eval($ARGV[2]); }
if ($#ARGV > 0) { $file = $ARGV[1]; }
print "file $file, size $size\n";
open(FILE, ">", $file) || die("open $file failed: $!");
truncate($file, $size) || die("truncate to %size failed: $!");
i.e. just trunc it to size but don't allocate blocks. The perl script is
more efficient: the dd allocates 512 bytes in the last block, the perl
script allocates 0.
As you reference unallocated blocks in the file, the OS gives you ZFOD
(zero-filled) data back for each block that was not allocated at file
creation.
All OSes will gives you zero-filled data as a security measure: in the
old days, we had great fun doing this:
open(some file)
truncate(to a large value)
read(the whole damn thing)
you could troll for all kinds of stuff that way. People actually wrote
'security' programs to open files in this way, then write them with
zeros to make this impossible -- I am not kidding.
Anyways, I don't know why this failed ...
ron
