On Apr 14, 7:03am, Stephan wrote:Yes, definitely. Think about it. With a raw disk, no translation
}
} my disk line looks like this:
}
} disk = [ 'file:/opt/xen/vm00.img,0x1,w' ,
} 'file:/opt/xen/NetBSD-6.0-amd64.iso,0x04,r' ]
}
} The disk image was created with qemu-img-xen and is assigned to a vnd
} device. I suspect that it is a sparse file.
}
} Is there a better solution (LVM perhabps? :)
is required; just convert xbd0 into the backing device. With a
partition, a constant offset is added to the block number, then read or
written. With an LVM, the block is mapped to a block in a PV, which is
then mapped to a partition or raw disk.
With a file you have to go through the file system. This means
calculating which block it should be in the file (the xbd block size
will rarely match the file system block size). Finding the inode,
finding the direct or indirect blocks. Finally finding which block it
should be on the partition. If the backing file is a sparse file, then
you also have the possibility that the block in the file hasn't been
assigned yet. That means searching the superblocks for a free block,
claiming it, and adding it to the file, before being able to write to
it.
Using a file for backing storage means that the system has to do a
lot more work. As somebody else said, for production use, you should
probably be using some sort of "physical" device. I put physical in
quotes since LVM isn't technically a physical device, but rather a
mapping layer. However, it is very close to the physical devices and
doesn't take much time.
I am (I use LVM). Many people do. Also, some of the project
} Regards,
}
} Stephan
}
} PS: Nobody using a NetBSD based Dom0??
servers are.
}-- End of excerpt from Stephan