VMFS File System Reconstruction (Part 3)

In the last two sections we covered the coarser portions of the VMFS file system. First we looked at what a volume consists of and the best way to find a volume on a storage device where the file system has been corrupted or lost (See VMFS File System Reconstruction – Part 1). In addition DTI provided a software tool to scan a storage device and search for volume specific attributes and in return display those attributes in an easy to read format. This tool can be downloaded here – VMFS Volume Finder. Those attributes were to be used in reconstructing a GPT/EFI partition handler.

In order to mount a volume it is necessary to have a fully functional GPT table definition that resides on disk. This was the subject of our second file system component definition (See VMFS File System Reconstruction – Part 2). We discovered how the GPT works and how the file system as well as the boot loader uses it to mount volumes. In addition DTI provided a software tool that allows for the editing of the GPT table and ultimately its repair that can be downloaded here – VMFS GPT Builder.

These two segments of the file system are critical to the functioning of VMFS as well as any file system. These are generic in nature and can support any file system type as well as any operating system. As the granularity of the file system becomes finer the low level file handler becomes increasingly unique to the operating system. In other words, Microsoft uses a two tiered approach for storing and displaying the file system. These include the Master File Table (MFT) for block and data storage and the INDX handler which is used to display the file names and folders. One stores the data necessary to find the contents of the file, the other displays a very limited amount of data about the file. Things such as size, date, name, and the like are stored via INDX within a sorted format for speed of display and easy access to the primary index which is the MFT. This formula is used throughout the world of file systems where there is a file name index and a file data index. VMFS is no different.

VMFS Inode Explanation

VMFS stores the data about a file in a mechanism called an inode. An inode very simply defined is the information necessary to find and use the data within a file. In other words, if you have the inode then you have ninety percent of the information necessary to use the data from a file on a storage device. It would seem then that when a file system is corrupt one should use any means necessary to find the inodes and use those as a tool to recover files from the file system since the inode is the heart of the file system. There are several elements necessary before an inode can be used that define the structure of the file system.

First, all file systems are relational in respect to where the volume starts. All references to the data within the file system are based upon the beginning of the file system and not the physical device. In other words the first block of data within a volume does not start at sector zero. A volume does not start on the same sector as the physical device. Block zero on a device does not correspond to block zero on a volume. As an example, the VMFS file system does not start at sector zero of the drive. The few times I have installed ESXi 5.x on a device the VMFS partition started at sector 10229760. This is approximately five gigabytes down the storage device. One of the main reasons that ESXi does this is to have enough room to support several maintenance partitions that aide in administering a VMFS file system.

This relational symbiosis between the device and the volume is called the association between the physical storage device and the logical volume. In every operating system there is a mechanism that handles the translation between the physical device and the logical volume. The fly in the ointment is that each operating system has its own set of parameters as to where to store the volume. First of all it is not common knowledge as to where an operating system will start a volume, secondly and more importantly many times there is a dependency upon the size of the storage medium that dictates where a volume is to be stored. This is why the first piece of software given to you by DTI that finds the VMFS volume and where it is stored is of immeasurable value when endeavoring to rebuild a VMFS file system. You cannot be off even one sector or the entire data set will be skewed.

Secondly, the block size of the physical device does not necessarily correspond to the block size of a volume. There are many reasons as to why the volume block size will not correspond to the physical device size:

• First, the block size of the volume allows for a better indexing method in order to find the blocks.
• Second, a block size can be defined to match the use of a volume. Microsoft defaults to a block size of 4096 bytes. However, there are parameters that can be defined when formatting a drive that can either raise or lower the block size. If a particular volume is to store very large video files then a larger block size can be used to help keep down the amount of read calls to the device and can work in concert with the cache of a physical device in order to make the data access faster.

VMFS uses a very large block size. The default is 1048576 bytes (1 MB) and can go to as high as 8388608 bytes (8 MB). VMFS is designed to handle very large files in support of virtual machine files. A VMDK file will normally be several gigabytes in size and a larger block size allows for the expeditious handling of large chunks of data.

VMFS Inode Components

The block size, volume size, and many other pertinent pieces of information are stored in the on disk volume structure. This volume super block as well as the related GPT information forms the backbone for the relational handling of the inode. There are several parts of the inode that are necessary in order to recover a file:

• First and foremost is the block map. In a VMFS block map each value not only holds an offset into a support file, it also holds meta data that defines the block type. There are file descriptors, file blocks, sub blocks, and pointer blocks that map where the data is currently stored within a volume.
• Second there is a set of dates, the creation date, last access date, and modified date that are stored in a simple format that can easily be translated for user viewing.
• Third, there is the file size which in conjunction with the block map can act as a checks and balance to make sure that the block map matches the size of the file.

There are several other items within the inode as to type, mode, and relational data which points to support files that translate a block id into a usable value that will point to the data. Of most importance here is that a translated block id that points to actual data must be then reduced to a logical block, and then a physical block in order to access the data. Here is the formula for block id to data: BlockID ->Block Type->Translate Block->Data Block->(LogicalBlock =(BlockSize * DataBlock)->(LogicalBlock + Volume Offset)->PhysicalBlock

The Physical Block is the value used to pass to the read operation to gather the data from the storage device. There will be another step added to this if an LVM is defined, and a multitude of steps added if a RAID is involved. Normally the RAID translation is transparent to the operating system and those calculations are performed by the card firmware.

VMFS Inode Scan – Recovery Software

Just like many other building blocks of a file system the inode for VMFS has a magic value tied to it. The software provided by DTI which can be downloaded here will help you in finding the inodes by using the inode magic value. Download VMFS Inode Scanner.

The final article will be about how to put all of these pieces together and using some source code of mine compile and recover files that have been lost on a VMFS file system.