Since this is a bit OT to the original post, I hope some will bear this tangent which I think is still useful.
An attempt to describe Virtual Disk Block mapping to Physical Disk Blocks (as I understand it) and understand Disk Block Alignment
What is this virtual disk file which is commonly used by various virtualization technologies?
The following applies to the most common implementation of the virtual file system, which is within what might be called at times a “loopback” or “backing” file. The file is mounted on a loop device for use as an entire disk for a Guest operating system.
In simplest terms, what is this “alignment” issue?
When an app reads data in a virtual disk, it will look at a file system that resembles a real, physical file system. But because the file system is virtual, the data will be retrieved not from the actual physical disk blocks but the mapped virtual blocks. If the virtual blocks map exactly to physical blocks , then retrieving the data should be nearly exactly the same as reading directly from the physical disk. But, if the virtual block is mis-aligned, the mapping may straddle multiple physical blocks which would have to be read. If the file is large and fragmented, then this effect can be magnified many, many times causing extreme disk I/O degradation.
Note that some references will describe “partition” alignment, but in its simplest terms, there is no entire partition that needs to be aligned, it’s only to get the disk blocks aligned so the starting edge of the first partition of the virtual disk is all that is important… After that, everything else should be automatically mapped based on that first block.
A more detailed description of virtual block to physical block mapping(may make your head spin)
Files are generally “free floating.” Unlike partitions which have fixed boundaries (in particular the physical disk) files are generally “self-aligning” – ie. the HostOS will automatically write any file in a way that it will <start> at the beginning of a block although it may not always fill disk blocks with data completely. So, there is no problem with alignment when you’re talking about files as seen by the HostOS.
The trick then is for virtual disk files to align their internal file systems and partitions so that when a block is written and read within the virtual disk file, the virtual disk blocks should correspond to physical disk blocks, else suffer potentially massive I/O penalties because of the need to read a very large number of additional disk blocks to acquire the same data.
The way this seems to be accomplished is to map virtual disk blocks 1:1 to physical disk blocks. The simplest scenario to envision is if both virtual and physical disk blocks are the same size. In this case, every virtual disk block is mapped exactly to a physical disk block.
Now, note that this all works well regardless whether the disk is fully allocated or “dynamically growing.” The actual size of the growing disk is whatever number of virtual blocks (which are automatically mapped to physical blocks). If the disk needs more disk blocks up to its specified limit, new blocks are simply mapped. And again, because the overall disk file is automatically already aligned and the internal disk layout and content is irrelevant at the block level, it all works fine.
So, how does a virtual file system become mis-aligned (ie How to avoid mis-alignment)?
Cause #1
Windows file systems are offset, unlike file systems used by any other OS the Windows file system does not start exactly on the beginning partition edge. This should not be a problem if you create a virtual disk file and use that file on the machine where it was created, but if you move and re-deploy that file to another machine you may see mis-alignment. Because all *NIX file systems do not have this offset, you can create and re-deploy virtual disks containing *NIX file systems to any other physical machine and not see an alignment problem.
Cause #2
It would be nice if the entire world used the same size physical disk block size, but as disks have grown in size from the floppy to terabytes (and larger) in size, the same block size is not practical to maintain fast disk I/O. Although smaller disk block sizes are still best for efficiency (less waste), most people would not sacrifice efficiency for speed, particularly if you store fewer and larger files. To minimize the possibility of mis-alignment, every block size has been and likely forever will be a multiple of the first size (256kB). When a disk is mounted in an OS, the disk’s physical characteristics including block size is automatically managed by the BIOS and OS so that all functions at a higher level don’t have to worry about how this all works, and usually all is well. But, when you lay a virtual file system’s virtual blocks on the actual physical blocks, it all <usually> works without an issue. Because there is not an exact 1:1 virtual to physical block mapping, there can be corner scenarios where multiple additional physical blocks might have to be read to retrieve the same amount of data, so a Virtual Admin needs to be aware of this possibility.
I suspect disk block mis-alignment, what are some common ways to resolve?
The following are only quick recommendations which resolve common issues but will not necessarily resolve a particular issue (ie Google your exact symptoms if necessary)
- Defrag(both within the disk file and the HostOS file system), zero empty space and compact your disk file.
- Move the diskfile off the existing HostOS partition and then move it back again. This is the common, well-known method to defrag files without running a defrag utility.
- Again, Windows file systems are different. There should be specific instructions for your virtual technology and virtual disk format. So, when possible avoid Windows file systems and use only Linux file systems instead to just avoid these issues.
HTH,
TSU