Create Local Disk

The sample program presented in Virtual Disk API Sample Code creates virtual disk of type
MONOLITHIC_SPARSE
, in other words one big file, not pre-allocated. This is the default because modern file systems, in particular NTFS, support files larger than 2GB, and can hold more than 2GB of total data. This is not true of legacy file systems, such as FAT16 on MS-DOS and early Windows, or the ISO9660 file system for writing files on CD, or NFS version 2, or Linux kernel 2.4. All are limited to 2GB per volume. FAT and FAT32 were extended to 4GB in NT 3.51.
However, a
SPLIT
virtual disk might be safer than the
MONOLITHIC
variety, because if something goes wrong with the underlying host file system, some data might be recoverable from uncorrupted 2GB extents. VMware products do their best to repair a damaged VMDK, but having a split VMDK increases the chance of salvaging files during repair. On the downside,
SPLIT
virtual disk involves higher overhead (more file descriptors) and increases administrative complexity.
When required for a FAT16 or early Linux file system, you can create
SPLIT_SPARSE
virtual disk. The change is simple: the line highlighted in boldface. The sample program could be extended to have an option for this.
static void DoCreate(void) {    VixDiskLibAdapterType adapter = strcmp(appGlobals.adapterType, "scsi") == 0 ?
                       VIXDISKLIB_ADAPTER_SCSI_BUSLOGIC : VIXDISKLIB_ADAPTER_IDE;    VixDiskLibCreateParams createParams;    VixError vixError;    createParams.adapterType = adapter;    createParams.capacity = appGlobals.mbSize * 2048;    createParams.diskType = VIXDISKLIB_DISK_SPLIT_SPARSE;    vixError = VixDiskLib_Create(appGlobals.connection, appGlobals.diskPath, &createParams, NULL, NULL);    CHECK_AND_THROW(vixError); }
You can split VMDK files into smaller than 2GB extents, but created filenames still follow the patterns shown in Table 1.
This one-line change to
DoCreate()
causes creation of 200MB split VMDK files (200MB being the capacity set on the previous line) unless the
-cap
command-line argument specifies otherwise.