Blogs  >  Breaking Change for Windows Azure Drive Beta in Guest OS 1.8 and 2.0

Breaking Change for Windows Azure Drive Beta in Guest OS 1.8 and 2.0

Breaking Change for Windows Azure Drive Beta in Guest OS 1.8 and 2.0


Windows Azure drives support the use of a local cache to improve performance of drives. With the upcoming Guest OS 1.8 and 2.0 releases, there’s a breaking change in the way this local cache is allocated.

Background

A Windows Azure application can request local storage in its service definition (.csdef).  Here’s an example:

    <LocalResources>
    <LocalStorage name="DriveCache" cleanOnRoleRecycle="true" sizeInMB="1000" />
    </LocalResources>

This example ensures that Windows Azure allocates 1000MB to a local storage resource called “DriveCache” for each role instance. When an application uses Windows Azure Drives, it can use such a local storage resource to allocate a cache for all Drives that are mounted.  Here’s a typical snippet of code that does that:

    LocalResource localCache = RoleEnvironment.GetLocalResource("DriveCache");
    CloudDrive.InitializeCache(localCache.RootPath, localCache.MaximumSizeInMegabytes);

Finally, when mounting a Windows Azure Drive, the instance can specify the amount of space to be allocated for that Drive, as follows:

    driveLetter = drive.Mount(driveCacheSize, DriveMountOptions.None);

The Breaking Change

Prior to Windows Azure Guest OS 1.8 and 2.0, the Windows Azure Drive cache was allocated as lazily as Drives were used.  With these new Guest OS releases, the entire cache is allocated up-front, and if there isn’t enough space in the local resource for the cache, the call to Mount() will fail with the error D000007F.

Due to an issue with how local storage resources are allocated, some of the requested space is unavailable for cache usage. That means that if your application declares a 1000MB local resource and then tries to allocate the full 1000MB across your Windows Azure Drive caches, the allocation will likely fail.

The workaround is to specify a local resource that’s 20MB larger than what the application uses. Here’s an example of allocating space for a Windows Azure Drive that uses 1000MB of cache space:

    <LocalResources>
    <LocalStorage name="DriveCache" cleanOnRoleRecycle="true" sizeInMB="1020" />
    </LocalResources>

    LocalResource localCache = RoleEnvironment.GetLocalResource("DriveCache");
    CloudDrive.InitializeCache(localCache.RootPath, localCache.MaximumSizeInMegabytes);
    driveLetter = drive.Mount(1000, DriveMountOptions.None);

Applications that would like to preserve the previous cache allocation behavior can specify an earlier Guest OS version. Here’s an example to specify Guest OS version 1.7:

    <ServiceConfiguration serviceName="MyService" osVersion=" WA-GUEST-OS-1.7_201009-01 ">
     <Role name="MyRole">
       …
    </Role>
    </ServiceConfiguration>

 2/23/2011 - Update for OS 1.9, 2.1 and beyond

Beginning with OS versions 1.9 and 2.1, if there is insufficient space on the local storage resource to accommodate the Azure Drive Cache specified in the mount call, Windows Azure will create a smaller cache to fit in the available space. That means you will no longer see cache allocation failures due to insufficient space as was the case with OS versions 1.8 and 2.0.

 

Windows Azure Storage Team

 

Comments (0)