Shulou(Shulou.com)06/02 Report--

In the Citrix PVS architecture and products, the storage hard disk at the end uses the virtual hard disk VHD/VHDX developed by Microsoft in the virtualization era. The VHD/VHDX format is a publicly available image format specification that allows the hard disk to be encapsulated in a single file for use by the operating system as a virtual hard disk as a physical hard disk. These virtual hard disks can host local file systems (NTFS,FAT,exFAT and UDFS) while supporting standard hard drives and file operations. The VHD file was originally used for Windows7,Windows Server 2008 Phantom Virtual Server and Windows Virtual PC as well as Hyper-V. Then Citrix PVS also used the VHD virtual hard disk. With the release of Microsoft Windows Server 2012 and the development of a new file system, the VHD format needs to adapt to these changes. So a new version of VHD format, called VHDX, was introduced in Windows Server 2012. The new VHDX supports the latest ReFS file system and has greater storage capacity. It also provides data corruption protection during power failures and optimizes the structural alignment of dynamic and differential hard drives to prevent performance degradation on physical hard drives in new large sectors.

Today, we will introduce the related technologies of VHD/VHDX virtual hard disk:

1. How does it communicate with the operating system?

2. What is the architecture of VHD/VHDX virtual hard disk, and what is the difference between VHD/VHDX virtual hard disk and physical hard disk?

How does the VHD/VHDX virtual hard disk communicate with the operating system?

VHD/VHDX we can say that she is an image file, can also be said to be a virtual hard disk. Because they represent an image file for the file system and a hard disk for the hard disk system. So Microsoft's VHD/VHDX virtual hard disk can be defined as using an image file to simulate the physical hard disk and store data.

In our operating system, the file system recognizes files whose VHD/VHDX image files are .vhd or .vhdx. Then the virtual hard disk drive system integrated or installed in the operating system loads the VHD/VHDX image file into a local hard disk partition and reads and writes like a normal physical partition. After uninstalling the virtual hard disk, the virtual hard disk partition disappears, leaving only the image file. After the virtual hard disk disappears, the system cannot access the files in it, nor can it perform any operations on the files stored in the virtual hard disk.

Under the Citrix PVS architecture, what if the Windows operating system recognizes and manages the VHX/VHDX virtual hard disk?

Let's start with VHD:

In Windows, the VHD virtual hard disk is managed, mounted, and created through VHDAPI. The architecture diagram is as follows:

VHD APIs based on VDS

In the figure, based on user mode, we can manage, mount, create, and destroy VHD virtual hard disks through VDS's Windows VHD API. VDS is Virtual Disk Service, Chinese abbreviation virtual disk service, is a kind of Microsoft Windows service, can execute query and configuration operation according to the request of end user, script and application. The service extends the existing storage capabilities of the Windows Server operating system by:

Provides API for existing volume and disk management capabilities in Windows. It includes the corresponding API for the VHD virtual hard disk function.

Unified volume management and hardware redundant independent disk array (RAID) management under a single API.

However, VDS does not perform the following storage management functions:

Hardware subsystem management, such as temperature monitoring or disk array performance statistics monitoring.

Storage area network (SAN) architecture management, such as storage partitions connected by host-based adapters (HBA).

To learn more about how an application or operating system can call VHD API provided by VDS, let's take a look at the architecture of VDS.

VDS defines three interfaces: a single interface between the application layer and the service, and two interfaces between the service and the provider program in the data layer. The following figure shows the architecture of VDS:

The N-tier architecture enables VDS to coordinate with file system functions, synchronize provider activities, and arbitrate between applications. VDS provides uniform functionality to applications between applications and providers, even though some underlying providers may lack such consistency.

The service implements common functions: formatting volumes, adding and removing drive letters or mounting folders, and managing unallocated disks (disks without partition information). VDS also returns event notifications to registered applications.

In other words, under the Citrix PVS architecture, the PVS console can manage the VHD virtual hard disk stored on the PVS physical hard disk by calling the VHD API of Windows's VDS.

VirtDisk.dll component

We say that the operating system manages the VHD virtual hard disk by calling the VDS VHD API of the storage system, but the specific VHD API function is stored in VirtDisk.dll, which is also located in user mode, which is a general library for VHD management API.

Kernel mode driver

The above two components are located in user mode and are custom modules for developers to develop. Drivers in kernel mode are not easy to modify. In kernel mode, there are three components:

VDrvRoot.sys: root virtual drive enumeration.

FsDepends.sys: nested volume dependency management.

Vhdmp.sys: VHD parser and dependency property provider.

In user mode, VirtDisk.dll implements real VHD image file operation by calling down these three drivers in kernel mode.

These three drivers are virtual device drivers, which virtualize an image file into a disk device and operate directly on the virtual device; at the same time, they are also a filter driver that modifies the IRP stream [the various operations of the application are transformed into various IRP requests through the kernel's Imaco manager. Virtual disk driver the IRP of the corresponding file system driver reads and writes to the virtual disk. To make IRP pass through the file system twice during delivery The request for the location of the file, after processing, is assigned to the real disk location, and the command and data are passed on. Because the virtual disk driver mainly modifies the IRP stream in the kernel state, the read and write flow in the user mode remains unchanged, while the IRP stream in the kernel state passes through the file system twice: the first pass through the file system is to operate the files in the virtual disk, and the second through the file system is to manipulate the image file.

After talking about VHD, let's introduce VHDX:

The VHDX format is only supported in WindowsServer 2012, and Windows Server2012's management of storage capabilities is different from 2008. For example, hardware subsystem management not supported in 2008, such as temperature monitoring or disk array performance statistics monitoring and storage area network (SAN) architecture management, such as host-based adapter (HBA) connected storage partitions. It is supported in Windows Server 2012. We can understand that Wind I am Server 2008 is a standard operating system, and Windows Server 2012 is both a standard operating system and a storage operating system. What is a storage operating system? Just like the traditional storage controller, it runs in the storage controller and has the function of managing NAS and SAN. That is, we can install Windows Server 2012 into the server and use the server as a storage controller.

In Windows Server 2012, Windows Storage Management API replaced the role and position of VDS (Virtual Disk Service). In other words, in Windows Server 2012 and R2, the management of VHDX virtual hard drives is done through WindowsStorage Management API. The CitrixPVS console finally manages the VHDX file by calling WindowsStorage Management API. The specific reading and writing process is the same as VHD, except that the corresponding services are different.

Second, what is the architecture of VHD/VHDX virtual hard disk, and what is the difference between VHD/VHDX virtual hard disk and physical hard disk?

If you put aside the physical components of a traditional physical hard disk, the physical components are nothing more than: interface, Buffer, master chip, RAM, motor (SSD is Flash particles). All that's left is a sequence of addresses from the 0~n-1, each containing 512B (bytes) of controls. Generally speaking, these addresses are called logical block addresses (LBA), and each block consists of 512B. The function of the partition table is to tell the system how many partitions there are on the disk, the start position and the end position. At present, there are two main disk partition table formats: MBR partition table and GUID partition table (GPT).

VHD/VHDX virtual hard disk has no so-called physical components, so the architecture of VHD/VHDX virtual hard disk is actually a sequence of addresses.

Again, let's start with VHD:

In Microsoft's VHD file format specification [http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc], there are three types of virtual hard disk VHD file formats:

Fixed virtual hard disk: the VHD image file is pre-allocated to the requested maximum size on storage. Fixed virtual hard disk uses VHD files of the same capacity to simulate a virtual hard disk of the same capacity. When the VHD file of fixed virtual hard disk is created, it has allocated all the space, determined the size, and does not change with the writing of data.

Scalable mode: also known as "dynamic" and "dynamically extensible" methods, VHD image files use only enough space on storage to store the actual data currently contained in the virtual disk. When creating this type of virtual disk, VHD API does not test the free space on the physical disk based on the requested maximum size, so you can successfully create dynamic virtual disk space with a maximum size greater than the available physical disk space. It is worth noting that the maximum size of a VHD dynamic virtual disk is 2040GB.

Differential mode: this method is a snapshot based on the master disk (fixed, dynamic, or differential VHD). It must have a basic VHD virtual hard disk as the parent virtual disk and cannot exist independently. After a differential disk is created on top of the parent virtual disk, any subsequent writes are written to the differential VHD image file and the parent VHD image file is not modified. Moreover, differential disks can be built on top of differential disks. This is the technology of CitrixPVS multi-version management.

Each of the above three types has its own file format.

1. Fixed virtual hard disk

Format of fixed virtual hard disk of VHD virtual hard disk:

The VHD format of fixed virtual hard disk is divided into two structures: data area and footer area. The data area structure is the same as the virtual hard disk, that is, the sector of the data area is sequentially mapped to the sector of the virtual hard disk. The footer structure is a common structure for all types of VHD files, located at the end of the file and occupying the size of a sector (512B bytes). The size of the entire file is the set VHD virtual hard disk size plus the footer size (a sector), that is, the true size of the VHD virtual hard disk is the value we set (such as 40GB) plus the size of a sector (512B bytes). The size of a fixed virtual hard disk is limited by the operating system. For example, on the FAT32 file system, the maximum size of a virtual hard disk is 4 GB.

What is in the footer area of the VHD virtual hard disk that is fixed to the virtual hard disk? According to the specification documentation for the VHD file format, the footer format is shared by all VHD types, that is, the footer area is common. Its footer area states:

Hard disk footer field

Size (bytes)

Cookie (identity)

eight

Features (property)

four

File Format Version (file format version)

four

Data Offset (data offset)

eight

Time Stamp (timestamp)

four

Creator Application (application creator)

four

Creator Version (Creator version)

four

Creator Host OS (Creator system)

four

Original Size (original length)

eight

Current Size (current length)

eight

Disk Geometry (disk parameter)

four

Disk Type (disk type)

four

Checksum (checksum)

four

Unique Id (unique ID)

sixteen

Saved State (save state)

one

Reserved (reserved)

four hundred and twenty seven

The full format is as follows:

0

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

Identification

Characteristics

File format version

Data offset

Time stamp

Application creator

Creator version

Creator system

Original length

Current length

Disk parameter

Disk Typ

Checksum

Unique ID

Unique ID

Existing state

Keep

Reserved (427 bytes)

As can be seen from the figure, the footer structure has a total of 512 bytes, which defines the VHD file logo, type, capacity and other related information. The meaning of each field in the footer area is described below.

(1) the Cookie ID occupies 8 bytes. Cookie is used to identify the original and unique creator of the hard disk image. Value is case sensitive. The value of the fixed virtual hard disk is the "conectix" string. Cookie is stored as an 8-character ASCII string, with "c" in the first byte, "o" in the second byte, and so on.

(2) the characteristic occupies 4 bytes. This field describes the specific functions supported by the file, and the common features are: none, temporary, and reserved. No feature indicates that the file does not have a specific function embedded; the property is temporary, indicating that this is a temporary VHD file that will be deleted when the computer is shut down; under the reserved feature, the value of this bit must be set to 1.

Function

Value

No features are enabled

0x00000000

Temporary

0x00000001

Keep

0x00000002

(3) the file format version accounts for 4 bytes. Indicates the version information of the VHD. This field is divided into major / minor versions and matches the version of the specification used when creating the file. The two most effective bytes are used for the major version. The minimum valid two bytes is a minor version. This must match the file format specification. For the current specification, this field must be initialized to 0x00010000.

(4) the data offset accounts for 8 bytes. This field holds the absolute byte offset from the beginning of the file to the next structure. This field is used for dynamic and differential disks, but not for fixed disks. For fixed disks, this field should be set to 0xFFFFFFFF.

(5) the timestamp occupies 4 bytes. This field stores the creation time of the hard disk image. This is the number of seconds since the timing of the UTC/ GMT time zone began on January 1, 2000.

(6) the application creator occupies 4 bytes. This field is used to record which application created the hard drive. This field is a left-aligned text field. It uses a single-byte character set. If the hard drive is created by Microsoft Virtual PC, write "vpc" in this field. If the hard disk image was created by MicrosoftVirtual Server, write "vs" in this field. Other applications should use their own unique identifiers. Each application has its own unique identifier in Windwos.

(7) the creator version accounts for 4 bytes. This field holds the major / minor version of the application that created the hard disk image.

(8) the creator system occupies 4 bytes. This field stores the type of host operating system on which this disk image was created.

(9) the original length is 8 bytes. This field stores the size of the hard disk, in bytes, from the perspective of the virtual machine when it was created. This field is used for informational purposes.

(10) the current length is 8 bytes. This field stores the current size of the hard disk (in bytes) from the perspective of the virtual machine. In a fixed virtual hard disk format, this value is the same as the original size when the hard disk was created. In dynamic mode, this value can be changed depending on whether the hard drive is expanded.

(11) the hard disk parameters account for 4 bytes. This field stores the track, head, and sector values of each track of the hard disk.

Disk parameter field

Size (bytes)

Cylinder

two

Heads

one

Sectors per track/cylinder

one

When the hard disk is configured as an ATA hard disk, the ATA controller uses CHS values (that is, tracks, heads, sectors per track) to determine the size of the disk. When a user creates a hard disk of a certain size, the size of the hard disk image in the virtual machine is smaller than the size of the user-created hard disk image. This is because the CHS value calculated from the hard disk size is rounded down.

(12) the disk type accounts for 4 bytes.

Disk Type Field

Value

None

0

Reserved (deprecated)

one

Fixed hard disk

two

Dynamic hard disk

three

Differencing hard disk

four

Reserved (deprecated)

five

Reserved (deprecated)

six

(13) the checksum occupies 4 bytes. This field only verifies the footer area of the VHD file and does not include the data section. The checksum is calculated by removing the information from the checksum field in the footer. If there is an error in the checksum, the file is considered corrupted.

(14) the unique ID occupies 16 bytes. Each hard drive has a unique ID to identify the hard drive. The unique ID is a 128-bit universal unique identifier (UUID). This field is used to associate the parent hard disk image with its differential hard disk image.

(15) the saved state occupies 1 byte. This field holds a byte flag that describes whether the system is in a saved state. If the hard drive is saved, the value is set to 1. Unable to perform compression and expansion operations on the hard disk where the state is saved.

(16) 427 bytes are reserved. The reserved field of this field, as its name implies, is used for possible parameters and field extensions in the future, and the data stored in it is all 0. Its size is 427 bytes.

2. Scalable (dynamic) virtual hard disk

Because of the dynamic nature of the scalable VHD virtual hard disk, it is different from the VHD format of the fixed virtual hard disk. The scalable VHD size varies dynamically with the data being written. For example, when you create an extensible VHD file for 60GB, its initial size may be only a few hundred MB, but with the continuous writing of later data, the extensible VHD file increases gradually, and finally reaches the maximum value of 60GB. The data stored in the middle is random and disorganized. So there has to be something like a log book to record that the data that is added later is stored in that sector of that cylinder.

The VHD extensible virtual hard disk format is represented in the specification document as follows:

The logical structure diagram is shown as follows:

As you can see from the figure above, an extended VHD file consists of a footer backup area, a header area, a block allocation table, a data area, and a footer area. The footer backup area is a backup of the footer area, which is located in sector 0 of the file; the header area is a fixed length of 1024 bytes, located in sectors 1 and 2 of the file; the block allocation table is located behind the header area, and each entry accounts for 4 bytes. It dynamically expands the sector with the growth of data, not of fixed length. The data area is located behind the block allocation table, and each data block includes the sector bitmap and block data, which are 512 bytes and 2 MB respectively, which also dynamically expands the sector with the growth of the data and is not fixed in length; the footer area is 512 bytes, which is the same size as the footer area of the fixed virtual hard disk VHD, except that the key value is different, which is located in the last sector of the file.

1. Footer backup area

It is a backup of the footer area, whose data is the same as the footer area, so you can understand the footer area, which is in the above fixed virtual hard disk and described in detail.

2. Head area

The header area of the extensible VHD represents an overview of the file, including block size, block allocation table location and number, and important information about differences.

In the VHD format specification document, the format of the extensible VHD file header is shown in the following table:

Expandable disk header field

Size (bytes)

Cookie (identity)

eight

Data Offset (data offset)

eight

Table Offset (table offset)

eight

Header Version (header version)

four

Max Table Entries (maximum table entry)

four

Block Size (block size)

four

Checksum (checksum)

four

Parent Unique ID (unique ID of the master disk)

sixteen

Parent Time Stamp (master timestamp)

four

Reserved (reserved)

four

Parent Unicode Name (Unicode name of the master disk)

five hundred and twelve

Parent Locator Entry 1 (master locator entry 1)

twenty-four

Parent Locator Entry 2 (master locator entry 2)

twenty-four

Parent Locator Entry 3 (master locator entry 3)

twenty-four

Parent Locator Entry 4 (master locator entry 4)

twenty-four

Parent Locator Entry 5 (master locator entry 5)

twenty-four

Parent Locator Entry 6 (master locator entry 6)

twenty-four

Parent Locator Entry 7 (master locator entry 7)

twenty-four

Parent Locator Entry 8 (master locator entry 8)

twenty-four

Reserved (reserved)

two hundred and fifty six

Its logical structure is shown in the following figure:

0

one

two

three

four

five

six

seven

eight

nine

ten

eleven

twelve

thirteen

fourteen

fifteen

sixteen

seventeen

eighteen

nineteen

twenty

twenty-one

twenty-two

twenty-three

Identification

Data offset

Table offset

Header version

Maximum table entry

Block size

Checksum

Unique ID of the master disk

Unique ID of the master disk

Master disk timestamp

Keep

Master Unicode name

Master Unicode name (512B bytes)

Master locator entry 1

.

Master locator entry 8

Reserved (256B bytes)

A detailed description of the extensible VHD virtual hard disk header field is provided below.

(1) the Cookie ID occupies 8 bytes. The saved value of this field is cxsparse. This field identifies whether the header is a legal header field.

(2) the data offset accounts for 8 bytes. This field contains the absolute byte offset of the next structure in the hard disk image. It is not currently used by any existing format and is set to 0xFFFFFFFF by default.

(3) the table offset accounts for 8 bytes. This field stores the absolute byte offset of the block allocation table (BAT) in the file. Because the first two fields are of fixed length, the block allocation table always starts at 0x600 and the field is fixed as 0x600.

(4) the header version accounts for 4 bytes. This field is used to store the version of the extensible VHD virtual hard disk header. This field is divided into major / minor versions. The lowest valid two bytes represent the minor version, and the highest two valid bytes represent the major version. This must match the file format specification. For this specification, this field must be initialized to 0x00010000. The major version will be added only if the header format is modified to be no longer compatible with older versions of the product.

(5) the maximum table entry is 4 bytes. This field holds the largest entry that exists in the BAT. This should be equal to the number of blocks on disk (that is, disk size divided by block size).

(6) the block size accounts for 4 bytes. This field defines the capacity of the block. Block is the expansion unit of dynamic and differential hard disk. It is stored in bytes. This size does not include the size of the block bitmap. It is only the size of the data portion of the block. The sector of each block must always be to the power of 2. The default value is 0x00200000 (indicating that the block size is 2 MB).

(7) the checksum occupies 4 bytes. This field holds the basic checksum of the dynamic header. It is a complement to the sum of all fields except the header field, which is the same as the checksum calculation in the footer area. If checksum verification fails, the file is determined to be corrupted.

(8) the unique ID of the master disk occupies 16 bytes. This field is used to distinguish between hard drives. The differential hard disk stores the 128bit UUID of the master disk. This field is set to zero in the expandable VHD virtual hard disk.

(9) the master timestamp occupies 4 bytes. This field stores the modification timestamp of the master disk. This is the number of seconds since the time zone UTC / GMT calculated since January 1, 2000, 12-0-00-0-0-0-0-0-0-1-0.

(10) 4 bytes are reserved. This field is set to zero.

(11) the Unicode name of the master disk occupies 512 bytes. This field contains the Unicode string (UTF-16) of the master file name.

(12) the master locator entry occupies 192 bytes (8 entries, 24 bytes each). These entries store the absolute byte offset in the file of the master disk locator that stores the differential hard disk. Used to migrate VHD files between different platforms. This field is used only for differential disks and is set to zero for dynamic disks.

The following table describes the fields within each locator entry.

Master locator table field

Size (bytes)

Platform Code

four

Platform Data Space

four

Platform Data Length

four

Reserved

four

Platform Data Offset

eight

The platform code occupies 4 bytes. The platform code describes which platform-specific format is used for the file locator. For Windows, the file locator is stored as a path (for example, "c\ disksp_w_picpaths\ ParentDisk.vhd"). On Macintosh systems, file locators are binary large objects (blob) that contain aliases. The master locator table is used to support cross-platform mobile hard disk images.

Some current platform code includes the following:

Platform Code

Description

None (0x0)

Wi2r (0x57693272)

[deprecated]

Wi2k (0x5769326B)

[deprecated]

W2ru (0x57327275)

Unicode pathname (UTF-16) on Windows relative to the differencing disk pathname.

W2ku (0x57326B75)

Absolute Unicode (UTF-16) pathname on Windows.

Mac (0x4D616320)

(Mac OS alias stored as a blob)

MacX (0x4D616358)

A file URL with UTF-8 encoding conforming to RFC 2396.

The platform data space occupies 4 bytes. This field stores the number of 512-byte sectors required to store the master locator.

The length of platform data is 4 bytes. This field stores the actual length of the master locator in bytes.

4 bytes reserved. This field must be set to zero.

The platform data offset accounts for 8 bytes. This field stores the absolute file offset (in bytes) that stores platform-specific file locator data.

(13) 256 bytes are reserved. Initialized to zero.

3. Block allocation table

Block allocation Table (BAT) is an important structure in extensible VHD file format, which stores the address mapping information from virtual hard disk to VHD file. It is pointed to by the Table offset field of the expandable virtual hard disk header.

The size of BAT is calculated during the creation of the hard disk. The number of entries in BAT is the number of blocks required to store the contents of the disk when fully expanded. For example, using a base unit block of 2 MB blocks to store 2GB data, the disk image requires 1024 BAT entries. Each entry is 4 bytes long, so the size is 4096 bytes. Starting with the first byte (0x600) of the block allocation table, all unused table entries are initialized to 0xFFFFFFFF

BAT always extends to sector boundaries. The maximum Table entry field in the expandable disk header indicates how many entries are valid.

The entry of BAT stores the block address of the virtual hard disk mapped to the absolute sector offset of the VHD file, indicating that the data in the block of the virtual hard disk is stored in the data block starting with that sector in the VHD file. If data is written to the block of the virtual hard disk, the entry of the corresponding block allocation table allocates space for the block in the VHD file; if the block of the virtual hard disk is not written, the corresponding block allocation table entry does not allocate space. This ensures that the virtual hard disk can write data to the VHD file at any time through the dynamic update of the block allocation table, and also illustrates the dynamic change of the VHD file capacity.

The specific flow chart is shown in the following figure:

The mapping of data blocks from a virtual hard disk to a VHD file is described in the figure above. The entry of the block allocation table is consistent with the number of virtual hard disk blocks, and the nth block of the hard disk corresponds to the entry n of the block allocation table, that is, an one-to-one corresponding relationship. this advantage is that it is convenient to find which data block the stored data is on when reading. However, the order of the blocks in the data area of the VHD file does not correspond to this. In the figure, the entry 0 of the block allocation table is the first block assigned from the block 0 of the virtual hard disk to the first block in the VHD file starting with a certain sector, that is, the data written to the block 0 of the virtual hard disk will be stored in the first block area of a certain sector of the VHD file, where a sector is the sector of the VHD file stored on the real hard disk. So we can straighten out the working mode of the VHD virtual hard disk quick allocation table:

1), the data is written to the virtual hard disk data block. The data is first written to the data block of the VHD virtual hard disk

2), record block allocation table. Then, according to the corresponding block allocation table written by the data block, the address mapping information of the corresponding virtual hard disk data block to the data block of the data area of the VHD file is recorded.

4. Data block

The data block consists of a sector location map and data. For VHD expandable hard drives, the sector bitmap indicates which sectors contain valid data (value 1) and which sectors are not used (value 0). For differential hard drives, the sector bitmap indicates which sectors are in the differential disk (value 1) and which sectors are in the master disk (value 0). The bitmap has a total of 512 bytes, or a sector size.

The block is the multiplier of the sector multiple. By default, the block size is 4096 512-byte sectors (2 MB). All blocks of the virtual hard disk must be the same size. This size is defined in the Block size field in the expandable virtual hard disk header.

All sectors in a block with corresponding zeros in the bitmap must contain 512 bytes of zeros on the virtual hard disk. Software that accesses disk images can take advantage of this assumption to improve performance.

After the block of the virtual hard disk allocates space through the block allocation table, it points to the sector bitmap in the data block, confirms the use of the block data area by viewing each bit of the sector bitmap, and then operates on the data.

After understanding the basics above, let's talk about how to implement a scalable virtual hard disk.

First, data blocks are allocated on demand. When you create a scalable virtual hard disk, no blocks are initially assigned to it. The newly created image contains only the data structures described earlier (including the extensible virtual hard disk header and the block allocation table BAT).

When data is written to the image, the expandable virtual hard disk expands new blocks of data for the written data. The BAT is then updated one by one to include the offset of each new data block allocated within the image.

VHD has a formula to let the virtual hard disk know which sector it maps from the data block of the virtual hard disk to the block of the VHD image file.

To calculate the block number from the referenced sector number, the formula is as follows:

BlockNumber = floor (RawSectorNumber / SectorsPerBlock)

SectorInBlock = RawSectorNumber%SectorsPerBlock

BlockNumber is used as an index for BAT. The BAT entry contains the absolute sector offset at the beginning of the block bitmap, followed by the block's data. The following formula can be used to calculate the location of the data:

ActualSectorLocation = BAT [BlockNumber] + BlockBitmapSectorCount + SectorInBlock

In this way, blocks can be allocated in any order while keeping them finding data through the sorting of the BAT.

5. Footer area

When a new block is allocated, the footer area must be pushed back to the end of the file.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.