VMware {code} Community
jedwards_mcafee
Contributor
Contributor

Stream Optimised extents

OVFTool makes a VMDK with a descriptor file something like :

  1. Disk DescriptorFile

version=1

CID=2bdc5c77

parentCID=ffffffff

createType=streamOptimized

  1. Extent description

RDONLY 16777216 SPARSE "dest-0.vmdk"

1) The createType string is not in quotes. All other descriptors I have seen look like createType="monolithicSparse" (or whatever the type is).

2) The extent type is "SPARSE" yet the format is rather different to an old-style Sparse extent. Is there a reason a new extent type string wasn't added?

Information about the extent is now in 3 places (createtype, extent description line, and the extent sparse header).

Obviously these aren't serious problems ... it might be useful to call them out in the documentation though.

Reply
0 Kudos
1 Reply
admin
Immortal
Immortal

1) The createType should be quoted, so this is a bug in OVFTool. It has no adverse consequences, though, since none of the tools require the quotes.

2) In addition to the "old-style" sparse extents, "SPARSE" also covers ACE compressed/encrypted sparse extents, and now "streamOptimized" which is a variant of the ACE compressed sparse extent format. "SPARSE" basically just means that the extent file has a sparse extent header which you must read to get more information about the extent.

We decided that "streamOptimized" was sufficiently different from "monolithicSparse" that it should have its own createType, mainly because of differences in how the grain tables are allocated (on-demand instead of pre-allocated), and the embedded metadata grains. The flags in the sparse extent header should be enough to stop "old" implementations from trying to access the disk, but by using a new createType we make extra sure.

There is some redundancy in the information in the disk descriptor, especially for monolithic formats. For other disk formats, such as raw devices, disks with mixed extents, etc., the information is necessary and not redundant. The disk descriptor is designed to handle all disk types in a consistent manner, which leads to the redundancy you observed in the simple case.

The VMDK specification () has more information about the streamOptimized format, though I'll admit it could be more elaborate.

Reply
0 Kudos