Re: [Libvir] PATCH: 0/7 Implementation of storage APIs
On Mon, Oct 29, 2007 at 02:49:16PM +0000, Richard W.M. Jones wrote:
Daniel P. Berrange wrote:
>As we did with virsh attach-disk/attach-interface, vs attach-device
>I think it would be helpful to provide a 'virsh vol-create' variant
>which took a handful of explicit args as an alternative to the XML,
>
>eg virsh pool-create --type fs xenimages /var/lib/xen/images
Yes, vital really, and even better if it's a libvirt call.
>NB, <format> is actually optional - it defaults to raw. Permissions
>should be optional, but currently aren't. Allocation is optional too,
>without it, you will get a sparse file.
I didn't really understand the semantics of <allocation>. It should be
<sparse/> AFAICS. This underlines actually why XML is so much more
slippery than real typing.
Basically, capacity is intended to be the logical size, while allocation
is the amount of space used on the host. So in the case of raw files,
capacity is the size we ftruncate to, while allocation is actual disk
blocks consumed.
With VMDK / QCOw & other auto-grow disk formats, capacity is a piece of
metadata embedded in the disk metdata - they don't use sparse files on
the host disk, while again allocation is disks blocks allocated up
front. So sparse is only really a concept for raw files where you litterally
do have a sparsely allocated file on the filesystem.
IIRC some logical volume managers also have a concept of volume size, vs
volume allocation, allowing blocks from the VG to be dynamically allocated
to LV, rather than fixed upfront.
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|