Author Archives: dilipcnaik

Windows Write Caching – Part 2 An overview for Application Developers

November 29, 2012 – 8:54 pm

Part1 of this blog presented an overview of the Windows storage stack.

Application programmers may use a number of interfaces to control the way their application data is cached or if they prefer, not cached and committed to disk media.

CreateFile API

Applications open a handle to a resource such as a file or a volume using the CreateFile API. One of the parameters to the CreateFile API is the dwFlagsAndAttributes parameter, which can be any valid combination of file attributes and file flags.

To avoid caching at the file system layer, an application should specify a valid combination that includes FILE_FLAG_NO_BUFFERING in this dwFlagsAndAttributes parameter. Some notable consequences of specifying this flag include:

  • Applications are expected to perform I/O that is in integer units of the volume sector size.
  • FILE_FLAG_NO_BUFFERING only applies to application data – the file system may still cache file metadata. Data and metadata may be flushed to disk by using the FlushFileBuffers API

Some well known applications such as Microsoft SQL and the Microsoft JET database (ships with Windows Server SKUs) specify FILE_FLAG_NO_BUFFERING with the CreateFile API.

Alternatively, applications may call the CreateFile API making sure that the FILE_FLAG_NO_BUFFERING flag is cleared in the parameter dwFlagsAndAttributes. In this case, it is likely that the file system and cache manager will cooperate to cache the application data, but there is no guarantee the caching will actually occur. A number of factors including the file/volume open mode specified in CreateFile, the data access pattern, and the load on the system will affect whether a particular application I/O is cached or not.

Note: The FILE_FLAG_NO_BUFFERING only affects file/volume data and does not apply to file/volume metadata, which may be cached even though FILE_FLAG_NO_BUFFERING is set.

Another relevant flag in the CreateFile API is FILE_FLAG_WRITE_THROUGH. Specified by itself, this flag ensures that both file/volume data and file/volume metadata are immediately flushed to storage media. Note that this does not mean the data does not traverse the cache. Referring to Figure 1, FILE_FLAG_NO_BUFFERING may mean that the data is written to Cache Manager and then immediately flushed from there. So the I/O may still be a buffered I/O.

  • Application developers favoring data integrity at the cost of reduced throughput should specify both FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH are set when invoking the CreateFile API.
  • Application developers favoring speed should make sure these flags are cleared when invoking CreateFile.
  • Application developers favoring a balance of throughput and data integrity need to read the section on FlushFileBuffers API.

Hardware Considerations

The main issues with hardware are the FILE_FLAG_WRITE_THROUGH parameter and how an operating system can handle it.

SCSI protocols define a Force Unit Access (FUA) flag in the SCSI Request Block (SRB). Early versions of the SCSI protocol (circa 1997) defined FUA as optional, while later specifications have made it mandatory. In situations where it is imperative that data gets committed to media, ensure that the deployed  storage hardware does support the Force Unit Access semantics and that this feature is not disabled.

In the enterprise world, NTFS has been deployed on a lot of non SCSI hardware which increasingly so includes SATA aka Serial ATA storage. The implementation of FUA in these devices is, at best, inconsistent. Even when implemented, the default is to turn it off, because of severe performance penalties.

Lower end PCs continue to use what is loosely termed IDE/ATAPI (ATA Parallel Interface which is ATA retroactively renamed) storage drives. Strictly speaking, this is more a family of protocols, rather than a single protocol. The ATAPI-4 specification is implemented in Windows 2000 and the ATAPI-5 specification in Windows Server 2003. Neither of these have any equivalent to the Force Unit Access semantic of SCSI. This is a long understood problem and Microsoft proposed in 2002 that the relevant standard be revised.

Note: The conclusion is that there is a possibility of data corruption due to drives caching data, especially so in ATA, IDE, ATAPI, and SATA devices, to name a few. This problem exists for other popular operating systems such as the Apple OS X and Linux as well. See the “FlushFileBuffers” section within this document. Also be sure to read the “NTFS” section further ahead in this blog.

FlushFileBuffers API

The FlushFileBuffers API can be used to flush all the outstanding data and metadata on a single file or a whole volume. However, frequent use of this API can cause reduced throughput. Internally, Windows uses the SCSI Synchronize Cache or the IDE/ATAPI Flush cache commands.

  • Application developers desiring a combination of speed and data integrity can
    • Specify ~FILE_FLAG_NO_BUFFERING and ~FILE_FLAG_WRITE_THROUGH when invoking CreateFile
    • Write data as needed using an appropriate API such as WriteFile
    • Periodically call FlushFileBuffers to commit the data and meatadata to storage media – the exact period at which this occurs is application specific
    • Application developers favoring data integrity at the cost of reduced throughput should make judicious use of this API, especially so when they specify only FILE_FLAG_NO_BUFFERING while invoking the CreateFile API. In other words, these applications are using FILE_FLAG_NO_BUFFERING to ensure data is committed to storage media and using FlushFileBuffers to ensure metadata is committed to storage media.
    • Application developers favoring pure throughput at the risk of potential data corruption should never use FlushFileBuffers API.
    • As reference 14 describes, FlushFileBuffers can be used to mitigate the hardware not supporting write-Through

Liberal use of the FlushFileBuffers API can severely affect system throughput. This is because at the file system layer, it is quite clear what data blocks belong to what file. So when FlushFileBuffers is invoked, it is also apparent what data buffers need to be written out to media. However, at the block storage layer – shown as “Sector I/O” in Figure 1, it is difficult to track what blocks are associated with what files. Consequently the only way to honor any FlushFileBuffers call is to make sure all data is flushed to media. Therefore, not only is more data written out than originally intended, but the larger amount of data can affect other I/O optimizations such as queuing of the writes.

There is also a bright side to this picture. While it is true that FlushFileBuffers, if handled properly by all involved layers, will flush all data and cause performance degradation, it can also help in preserving data integrity. An application that “forgets” to invoke FlushFileBuffers will still have its data committed to media due to other applications invoking this API.

FlushFileBuffers should be judiciously used as needed.

Hardware Considerations

The SCSI-3 protocol defines a command SYNCHRONIZE_CACHE that commits data from the storage cache to media. Hence SCSI devices are good candidates for applications that are highly sensitive to data being committed to media. However, it is always good practice to verify that  a particular SCSI hardware does implement the SYNCHRONIZE_CACHE command.

The relevant ATA/IDE specifications define an equivalent command FLUSH_CACHE. ATAPI-4 (relevant circa 2000) defines the FLUSH_CACHE command as optional; ATAPI-5 makes this command mandatory. As always, verify the exact functionality of a particular hardware and do not assume it implements the relevant standard precisely.

Client/Server application considerations

Both the Common Internet File Systems (CIFS) and the new SMB 2.0 protocols define a flush SMB command. Therefore the CIFS/SMB redirector built into Windows can easily propagate a FlushFileBuffers command over to a file server.

DeviceIOControl API

While data may be cached at the file system layer, it can (and does) occur at other layers such as the disk block level. For the purposes of this discussion, caching done within a disk or a disk controller is referred to as disk block caching.

Storage devices cache data to enhance throughput, but sometimes at the cost of data integrity. Some storage devices include their own battery backup to enhance data integrity.

Further increasing ambiguity is the fact that there is no standard manner to determine whether such caching is indeed occurring or not. Some storage systems have their own battery backed cache and hence under many circumstances, it may be OK to leave the data in this battery backed cached and treat it as being committed to media. Some of these storage systems ignore the command to commit data to media.

The DeviceIOControl API can be used to inspect block storage caching configurations and also potentially set these configurations. Both the caching policy inspection and setting have limitations as well.

Windows offers a number of ways for applications to programmatically affect the caching at the sector I/O level. Many of these interfaces consist of calling the DeviceIOControl API with some different function code. Windows NT 4.0 SP4 and higher versions of Windows require administrator privileges to submit SCSI pass-through requests. SCSI pass-through requests are submitted via the WIN32 DeviceIOControl API, which requires a handle to a file or a volume as a parameter. This handle is obtained via the CreateFile API and starting with Windows NT 4.0 SP4, the CreateFile function requires GENERIC_READ and GENERIC_WRITE to be specified in the dwDesiredAccess parameter of the CreateFile API.

Windows defines a number of IOCTL codes that may be used to inspect and control the disk block caching functionality. These include:

IOCTL_DISK_GET_CACHE

Returns information about whether the disk cache is enabled or not. The function works only where the disk returns correct information via a SCSI mode page.

IOCTL_DISK_SET_CACHE

-Sets disk caching functionality to be enabled or disabled. The function works only where the disk implements SCSI mode pages.

IOCTL_STORAGE_QUERY_PROPERTY

Windows Vista and higher versions of Windows support another interface to retrieve disk cache properties.

Pros

  • A single interface that applications can code to – in the absence of this single interface, applications would need to understand the nuances of various devices e.g. for 1394 devices, obtain page 6 of the mode data, but for SCSI compliant devices, obtain page 8 of the mode data, etc.
  • Windows implements the necessary details to retrieve  the information in a transport dependent manner (SCSI/IDE/etc) to surface the information
  • A richer interface that can provide information not just whether the disk implements a cache, but also what kind of cache
  • Time will tell whether this interface continues to be evolve and be populated with more data

Cons

  • Yet another interface that applications need to code to
  • Does not work for RAID devices
  • Does not work for Flash drives
  • Not yet widely implemented by storage vendors
  • Only available in the newer versions of Windows
  • Does not (yet at least) allow setting of caching properties

For an application to retrieve information about a device’s write cache property, use the STORAGE_WRITE_CACHE_PROPERTY structure with the IOCTL_STORAGE_QUERY_PROPERTY request.

NTFS and flushing behavior

NTFS, when introduced with Windows NT 3.X depended upon the SCSI Forced Unit Access behavior to ensure its meta data is flushed to media. As described above, NTFS has been deployed on a fair number of non SCSI devices, all of which have an inconsistent implementation of FUA. Perhaps the saving grace may have been that the consumer devices do not have a cache, and hence even without FUA, the data hits the media. In any case, what is worth noting is that all NTFS versions upto and including Windows 7 and Windows 2008 R2 depend upon FUA to ensure that NTFS. NTFS in Windows 8 has switched to using the FlushFileBuffers API instead of depending upon the Forced Unit Access behavior.

This concludes an overview of the knobs an application developer can twist and turn to influence application data write caching. Part 3 of this blog will present an overview of the knobs a system administrator can twist and turn to influence write data caching.

Posted in Hyper-V, NTFS, SSD, VHDX, Windows 8 | Comments (2)

Windows Write caching – Part 1 Overview

November 29, 2012 – 8:46 pm


Certain Windows applications such as database applications need to ensure their I/O is committed to media, even at the cost of reduced throughput. However, at times an administrator has faith in the hardware and is willing to accept a small risk of data corruption in favor of a higher throughput by allowing caching to occur .

This is a 3 part blog that concentrates on the write caching behavior in the Windows storage stack.

  1. Part 1 presents an overview of the Windows storage stack with specific reference to write caching
  2. Part 2 presents the “knobs” an application programmer can twist and turn to affect write caching
  3. Part 3 presents the “knobs” a system administrator can twist and turn to affect write caching

Windows Storage Stack

Figure 1 Windows Storage I/O Stack

Figure 1 shows a simplified overview of the Windows Storage I/O stack. Starting from the top of Figure 1,

  • Applications make I/O requests. Figure 1 concentrates on write requests and hence the unidirectional arrows from the application towards the disk media.
  • Depending upon the nature of the I/O (decided partly by the way the application opens a file or volume), some I/O requests completely bypass the Windows Cache Manager and go straight from the file system to the Volume Manager layer. This is labeled Unbuffered I/O in Figure 1. As will be explained later, applications can ensure that their I/O is Unbuffered.
  • Alternatively, Application I/O may traverse the buffered path labeled in Figure 1. While applications may strive to ensure their I/O is buffered, in reality, there is no way to ensure this. I/O is buffered depending upon a number of factors such as nature of file open, the type of I/O, the history of the application I/O, the load on the system, etc.
  • The Volume Manager performs sector I/O. While the application may strive to ensure that there is no caching at the sector I/O level, the reality is that applications have limited success in some cases. This is discussed in more detail within the document.

Different types of Write Caching

Irrespective of whether the data is written at the file system level or at the disk block level, write caching can be broadly classified into two categories:

  • Write-through caching:  where data is written to cache AND also written to non volatile media. The data integrity is high, but write performance is slower whereas read performance is enhanced
  • Writeback caching: where data is written to cache, the operating system write request is completed, and the data is lazily written to media at a later point in time. Writeback Caching emphasizes write performance, but at the possible loss of data integrity.

Part 2 of this blog will describe the APIs an application developer can use to control write caching behavior.

Posted in Hyper-V, NTFS, Uncategorized, VHDX, Windows 8 | Comments (0)

VHDX file investigations on regular spinning disk

September 30, 2012 – 11:29 pm

Refer my earlier blog on VHDX file best practices. This blog explains the details behind how I arrived at those recommended best practices. Based upon a TechEd talk, I ran a series of experiments with VHDX files. While the investigations led to the summary published in my previous blog, there also remain some unanswered questions. So far, my attempts to find answers to these questions have remained unfruitful. Presumably the appropriate Microsoft personnel are extremely busy. Once I publish what I found, I will publish my questions as purely that – questions, in the hope that some fellow MVPs may have some insight.

For the investigation, I created a Windows 8 based guest VM running on a Windows Server 2012 Hyper-V host. I created a dynamically expanding VHDX file and attached it as a SCSI attached volume to the Windows 8 guest. The investigation consists of performing a series of operations on the Windows 8 SCSI attached volume and observing the size of the VHDX file backing that SCSI attached volume. For the purposes of this particular blog, the VHDX file was placed on an external USB spinning hard disk, which was not thin provisioning capable.

Operation

VHDX file size in   bytes

Create an   empty dynamically expanding VHDX file that is not yet initialized and not yet   NTFS formatted

4,194, 304

 

Initialize   the disk as MBR partitioned & NTFS format the volume

205,520,896

Copy a   single file of size 949,350,400 into the VHDX file

1,178,599,124

Delete the   file, make sure it is deleted from recycle bin as well

1,178,599,124

Shut down   the VM

1,178,599,124

Run PS   cmdlet Optimize-VHD with Mode Retrim on the VHDX

1,178,599,124

 

The fact that Optimize-VHD did not shrink the VHDX file was both a little surprising and disappointing, but presumably the error is mine. After numerous presentations that claimed the TRIM/UNMAP commands flowed from the guest VM into the parent partition, I was under the impression that given a Windows 8 guest OS and a Windows Server 2012 Hyper-V host, the TRIM/UNMAP commands flowed natively. Perhaps they do, and I don’t understand it. But requiring a PS cmdlet to make them flow is not what I would call native.

The next experiment I performed was to see if the VHDX file reused space freed up

Operation

VHDX file size in   bytes

Create an   empty dynamically expanding VHDX file that is not yet initialized and not yet   NTFS formatted

4,194, 304

 

Initialize   the disk as MBR partitioned & NTFS format the volume

205,520,896

Copy a   single file of size 949,350,400 into the VHDX file

1,178,599,124

Delete the   file, make sure it is deleted from recycle bin as well

1,178,599,124

Copy the   file again

2,118,123,520

 

Note: The implication is quite obvious. Without any intervention, the VHDX fie does not neccesarily reuse the recently freed up disk space, even when the amount of new space required is exactly equal to the recently freed up space

The next experiment I consisted of using the PS cmdlet Optimize-Volume, again with the ReTrim option.

Operation

VHDX file size in   bytes

Create an   empty dynamically expanding VHDX file that is not yet initialized and not yet   NTFS formatted

4,194, 304

 

Initialize   the disk as MBR partitioned & NTFS format the volume

205,520,896

Copy a   single file of size 949,350,400 into the VHDX file

1,178,599,124

Delete the   file, make sure it is deleted from recycle bin as well

1,178,599,124

Run PS   cmdlet Optimize-Volume with Retrim option

1,178,599,124

Shut down   the VM

205,520,896

 Note: Shutting down the VM is not really an option in production systems, but it certainly is an option for people like my fellow MVPs running VMs on their laptops.

And now, let me describe the last, but most important experiment for this blog. I expect to write more blogs on this topic.

Operation

VHDX file size in   bytes

Create an   empty dynamically expanding VHDX file that is not yet initialized and not yet   NTFS formatted

4,194, 304

 

Initialize   the disk as MBR partitioned & NTFS format the volume

205,520,896

Copy a   single file of size 949,350,400 into the VHDX file

1,178,599,124

Delete the   file, make sure it is deleted from recycle bin as well

1,178,599,124

Run PS   cmdlet Optimize-Volume with Retrim option

1,178,599,124

Copy the   same single file again

1,178,599,124

 

Note: The implication again is quite obvious. Running the PS cmdlet Optimize-Volume allows the VHDX to reuse the newly freed up space.  

 

Posted in Uncategorized | Tagged , , , | Comments (2)

Best practices for utilizing VHDX files in Windows Server 2012

September 30, 2012 – 11:20 pm

A number of blogs and presentations have explained the advantages of VHDX files in Windows Server 2012 over the VHD files in Windows Server 2008. These advantages include:

  • VHDX files can host larger data volumes – in particular, VHDX files can host 64 TB volumes versus 2 TB for VHD files
  • VHDX files have  their metadata aligned on 1MB boundaries whereas VHD files have 512 byte sized metadata that cause alignment issues and in particular, cause significant slowdown when used with newer disks that use 4096 byte sectors instead of 512 byte sectors
  • VHDX files are more resistant to corruption

However, VHDX files have one more huge advantage that has not been as adequately explained, or at least, seems to be less widely known. This is the fact that VHDX files are much more disk space efficient in a number of ways, especially so when the system administrator follows proper best practices. This blog and some successor blogs will explain the necessary and sufficient conditions for each particular use case, and also lay out the best practices to obtain the maximum benefit.

In particular:

  • VHDX files declare themselves to be storage volumes capable of thin provisioning
  • When used properly, VHDX files based on appropriate type of storage can free up disk space and utilize the thin provisioning features of the underlying storage
  • Even when VHDX files are placed on regular storage, best practices will prevent the VHDX files from growing in size by reusing free space within the VHDX file

So what are the necessary and sufficient conditions to take advantage of these VHDX file features? They can be summarized as:

  • These tips apply to running Windows Server 2012 and Windows 8 as guest operating systems. I am hoping to find a way to have them apply to Windows Server 2008R2 and Windows 7 as well, but as of now, that is just a possibility and not a reality.
  • Separate the data volume from the system volume within the VM. Don’t just put data into the system volume
  • Seriously consider using dynamically expanding VHDX files rather than statically fully allocated VHDX files. Meta data overheads, for VHDX files have been considerably reduced in Windows Server 2012, VHDX files grow less often, and with the tips in this blog, they will grow even less often. The idea is to accept the minimal overhead of expanding VHDX files in exchange for storage space optimization. Note that if the VHDX file is placed on thin provisioned storage e.g. a thin provisioned Storage Space, using a fixed size VHDX file does not guarantee that the VHDX file will never face an issue of running out of disk space.
  • Always present the VHDX based data volume as either SCSI or virtual HBA attached storage within the VM .  
  • Periodically run a PS cmdlet to optimize the VHDX based volume. In particular, run the PS cmdlet Optmize-Volume with the ReTrim option. Optimize-Volume is described at this MSDN link, and the description is certainly incomplete. While the MSDN web page claims this PS cmdlet applies to only Windows Server 2012, it certainly also applies to Windows Server 8 as well. Yours truly has submitted the web page feedback and hopefully the page is updated soon. Further note that this PS cmdlet needs to be run with administrative privileges, again something the MSDN web page does not mention.

Details of the investigation that led to this summary of recommendations will be published in follow up blogs soon.   

Posted in Uncategorized | Tagged , , , | Comments (2)

Aligned I/O and large sector disks – VHD, VHDX, and VS 2012 install

July 28, 2012 – 7:10 pm

The issues of aligned disk I/O have been understood for a while. One example is where the Microsoft VHD file format ensured that ¾ of data blocks within a VHD file would be aligned on a 512 byte boundary, and not a 4096 sector boundary. See the Technet blog I authored a few years ago “Some observations on Dynamic VHD Performance”.

That makes using VHD files with large sector drives (which read and write data in 4k units) extremely painful. See the MSDN KB article “Using Hyper-V with large sector drives on Windows Server 2008 and Windows Server 2008 R2”. The KB article mentions a performance degradation of up to 30%.

The problem here is that Hyper-V performs non-cached I/Os which result in a Read, Modify, Write cycle as the KB article describes. For example, if 4kb of data needs to be written, and if that data spans 2 adjacent physical 4kb sectors, Windows needs to read 8kb, modify 4kb of this 8kb data, and then write back 8kb of data.

Recognizing the problem, the Hyper-V team introduced the VHDX file format in Windows Server 2012. Look at a fellow MVP blog “Why Windows Server Hyper-V VHDX 4k alignment is so important”

And now, let us return to my earlier blog about Visual Studio (VS) 2012 installer performing non-aligned writes. Since these are cached writes, the performance degradation on large sector disks will not be as noticeable. But just because one issues cached writes does not mean the data stays in cache until you are done writing to the file and close the file, when the cache is flushed. Since Visual Studio writes in a pattern where the first and last writes to a file are odd length bytes, and all intermediate writes are even bytes, the data in the cache, while the file is being written to, is always odd bytes in length. So should the cache get flushed, for any reason, you now have the equivalent of misaligned I/Os, and the penalty on large sector disks is even more noticeable.

I will be looking to buy a large sector disk and try installing VS 2012 to that disk. In the meanwhile, I would love to hear from any reader that has already tried this experiment.

Posted in Uncategorized | Comments (1)

The perils of alignment for memory access and disk I/O

July 28, 2012 – 6:30 pm

In my earlier blog, I described how Visual Studio (VS) 2012 is now a requirement for writing kernel mode drivers on both the x86/x64 Intel/AMD, and also the ARM version of Windows 8. So I installed VS 2012 RC on two different laptops and was unhappy with the installation time. I must place on my record my appreciation for the Visual Studio team, which has been very diligent in following up and looking into the issue. Of course, I will acknowledge that my belief of “it takes too long” could be incorrect, and I may be encountering unusual circumstances on both my systems. So with that caveat that perhaps “I am encountering a one off situation”, here we go with my analysis.
First, a couple of references are in order.

  1.  To quote from MSDN “In this document we explain why you should care about data alignment, the costs if you do not, how to get your data aligned, and what to do when you cannot. You will never look at your data access the same way again.” The point is; aligned memory access in Windows is very important.
  2. It is equally important to ensure that writes are aligned as well. Most current disks write data in 512 chunks called sectors. So if you write 512 bytes at offset zero, a single write suffices. But if you write 512 bytes at offset 1, the I/O spans 2 disk sectors. So a single write becomes read 2 disk sectors, copy over the new 512 bytes of data, and issue 2 sector writes, each of 512 bytes. So a 512 byte write becomes a 1024 byte read and a 1024 byte write. Here is an MSDN blog explaining among other things, the importance of aligned I/Os for SQL. And here is a another MSDN SQL blog explaining the importance of aligned I/O

Now back to the topic at hand – installing Visual Studio 2012 RC and analyzing possible causes for why it takes as long as it does. So I decided to investigate further, by tracing the I/Os using Sysinternals (now part of MSDN) tool Process Monitor.

Here is a screen shot showing a small part of the I/O of the installation. Note that I randomly located this I/O pattern. I also cursorily checked that other files have similar behavior; in particular, write an odd number of bytes at offset zero, and then proceed to write the rest of the file.

Image

For file DataCollection.dll, please notice

  1. The write at offset zero for 32,447 bytes
  2. The write at offset 32,447 for 32,768 bytes
  3. The write at offset 62,215 for 16761 bytes
  4. The total file size is 81,976 bytes and 32,447 + 32,768 + 16,761 = 81976

Now apply the logic of the references quoted – in particular, the importance of aligned memory access, and aligned disk I/O access.

At the very least, the each of the 3 I/Os will consist of a 1 or 3 byte copy, a copy of some N DWORDs, followed by a 1 or 3 byte copy. This could have been completely avoided by doing 3 I/Os, each consisting of an even number of bytes. There is a penalty to be paid for the 1 byte and 3 byte memory access.

I must admit that this trace is at the file system layer. It is certain that before the I/O hits the disk, which is a block mode I/O, the Windows Cache Manager and I/O subsystem will have intervened to make the I/O aligned and an integral number of sectors. There will still be some disk I/O penalties however, when some writes get split across 2 adjacent sectors. This could be avoided. Consider the case where say part of the file has been written, and is in cache. And the I/O pattern guarantees that there will be an odd number of bytes cached, until the final odd length write arrives. Now imagine that for some reason, the cache gets flushed before the last write arrives. This could be because the file is very large, or there is memory pressure. This means that the cache manager will zero fill a buffer until the end of a sector (an odd number of bytes) and then write out that sector. When the next write arrives, this just flushed sector needs to be read, the zero filled bytes are copied over with the newly arrived data, and then the same sector is written – again!

There is no perceivable advantage in making the I/O nonaligned – and significant potential harm. It is difficult to estimate how much VS 2012 installation will speed up, were the writes to be aligned.
There are other oddities as well in the trace, but I will write about those in future blogs.

I invite reader comments on whether they believe this I/O pattern is within acceptable bounds. For readers willing to trace their VS 2012 install, I would also welcome feedback as to whether they observe this pattern.

Posted in Hyper-V, NTFS, Uncategorized, VHDX, Windows 8 | Comments (0)

Developing kernel mode drivers for Windows 8

July 17, 2012 – 7:30 pm

I have been developing Windows kernel mode drivers for 10+ years now and notice that the Windows 8/Windows Server 2012 WDK brings some changes. This blog tries to highlight the changes in the hope that other developers will benefit.

I went through the mechanics of installing the Windows 8 WDK on 2 different laptops. So with the caveat “Your mileage may vary – maybe I hit the jackpot and my experience was unique”, here we go:

  1. WDK 8 requires that you first install Visual Studio 2012. See http://msdn.microsoft.com/en-US/windows/hardware/hh852362 and the listed System Requirements section that among other things, state “Before you begin, you must first install Visual Studio Professional 2012 RC or above”
  2. For now, Visual Studio 2012 is “free” since it is not yet a released product. Presumably, two different parts of Microsoft will soon tell us a couple of important data points
    1. The Visual Studio team will tell us pricing for the various different versions/SKUs of Visual Studio 2012
    2. A different part of Microsoft will tell us which SKUs are acceptable for compiling the WDK code samples and code developers write
    3. I am not referring to the new ARM based version of Windows called WindowsRT. I am referring to writing drivers for the x86/X64 platform. Even that one now requires Visual Studio 2012.
    4. Visual Studio is an excellent product for whom it works. A while back – as in 5 or so years ago, I abandoned it, primarily due to the long install time and resources it consumed in terms of disk space. The only use I had for it was the compiler. I use a different editor, and I use WinDbg in stand alone mode.  So when a previous version of the WDK (called the DDK at that time) shipped with compilers, I abandoned Visual Studio. I don’t seem to have the same choice any more.
    5. Depending upon which version of Visual Studio you install, and depending upon what choices you make during the installation, Visual Studio will take some time to install and occupy some GBs (certainly less than 10GB) of disk space.
    6. In case you are still reading, the WDK no longer downloads sample code. My gratitude to the people who posted this fact e.g. http://boardreader.com/thread/Samples_arent_installed_along_with_the_W_u8jjs__3e9c9b67-ea9f-4225-a268-5d5ece555568.html Presumably, this makes it easier for Microsoft to release new or updated code samples without shipping the whole WDK
    7.  The code samples are available at http://code.msdn.microsoft.com/windowshardware . Presumably Microsoft will release some scripts to download the samples in some sort of collection e.g. all the samples, all the USB samples, all the storage driver samples, etc. But meanwhile, one has to download the samples one sample at a time. While this saves on disk space, the savings are miniscule compared to the added GBs occupied by VS 2012.
    8. I must acknowledge that VS 2012 now provides an ARM capable compiler, something the old WDK did not.

We will have to wait and see what the VS 2012 requirement adds in terms of software licensing costs. I guess that is just “the cost of doing business” with Windows 8.

In the meanwhile, I look forward to attending the next plug fest and testing my driver(s) for CSV 2.0 compatibility.

Posted in NTFS, SMB, Windows 8 | Comments (0)

Windows 8, ReFS, and Extended Attributes

April 12, 2012 – 12:49 am

By now, a lot of my readers will be aware of the new ReFS file system in Windows 8. I personally believe ReFS will evolve, and will add support for some of the missing features. To recap, some of the features present in NTFS, but absent from ReFS (at least the ReFS in Windows 8 include:

  • No support for Extended Attributes
  • No support for Alternate Data Streams
  • No support for quotas
  • No support for bootable volumes

This is not a comprehensive list. I decided to look briefly at each of these features in a series of blog posts.

Extended Attributes are known to be used in two specific cases, if one believes some of the postings on the Internet, including on Technet forums. To be clear, I am not attributing these postings to Microsoft employees, I am simply saying users have posted on some Microsoft owned forums:

  • Internet Explorer and Windows use Extended Attributes to mark files downloaded from the Internet and provide a security warning when the user attempts to execute the file.
  • Windows Client Side Caching (yes, the name keeps evolving) uses Extended Attributes to mark files in its cache

What, if anything else, uses Extended Attributes ?

Since there was no convenient way, I wrote a small utility to examine a specified directory and inspect each of its component files and sub-directories to determine if any of them have Extended Attributes. I am happy to provide this utility free for any curious folks. I ran the utility on a Windows 8 Server box and a partial output is at the end of this blog.

What I found is that a number of Windows system files and directories use Extended Attributes.

It will be interesting to see what path Microsoft takes to improve ReFS functionality e.g. if and when Microsoft enhances ReFS to provide support for bootable volumes, will ReFS evolve to support Extended Attributes, or will Windows evolve to stop using Extended Attributes.

Here is the promised partial output

Directory \??\C:\Documents and Settings has Extended Attributes.

Directory \??\C:\ProgramData\Application Data has Extended Attributes.

Directory \??\C:\ProgramData\Desktop has Extended Attributes.

Directory \??\C:\ProgramData\Documents has Extended Attributes.

 File \??\C:\ProgramData\Microsoft\Windows\Hyper-V\Resource Types6FF76FA-2D58-4BAF-9F8D-455773824F37.xml has Extended Attributes.

File \??\C:\ProgramData\Microsoft\Windows\Hyper-V\Resource Types\118C3BE5-0D31-4804-85F0-5C6074ABEA8F.xml has Extended Attributes.

File \??\C:\ProgramData\Microsoft\Windows\Hyper-V\Resource Types\146C56A0-3546-469B-9737-FCBCF82428F4.xml has Extended Attributes.

File \??\C:\ProgramData\Microsoft\Windows\Hyper-V\Resource Types\19839BFF-6F04-4B24-B4B5-1AFCCBE729DE.xml has Extended Attributes.

Posted in Uncategorized | Comments (2)

Windows Server 8 NIC Teaming tips

March 12, 2012 – 4:10 pm

Some highly knowledgeable folks at Microsoft recently shared some very valuable tips during the recently concluded MVP Summit. This blog is a small sample of thse tips.

Prior to Windows 8, NIC Teaming has been a feature never officially supported by Microsoft. It was a third party offering from an OEM/IHV/ISV and all support for the feature had to be provided by the third party. I personally have spent considerable time debugging situations where a system start up service I wrote had issues. It turned out that my service could not connect to the Domain Controller because the NIC team was still in the forming stage and had not yet completed its initialization.

Windows Server 8 natively supports NIC teaming. Here are the highlights and tips:

  • NIC teams can only be formed between homogenous NICs. So two 1GB NICs can be teamed, or two 10GB NICs can be teamed, but you cannot team a 1GB and 10GB NIC.
  • If the individual NIC members each support Receive Side Scaling (RSS), the NIC team also supports RSS. Hence it is a good idea to team NICs that support RSS. The resulting NIC team is also highly capable and does not lose any functionality.
  • If the individual NIC members each support RDMA, the resulting NIC team does NOT support RDMA. Given how Windows 8 SMB 2.2 natively supports RDMA without modifying applications, it is a bad idea to team NICs with RDMA capabilities, and where the interconnect (routers, etc) also supports RDMA
Posted in SMB, SMB 2.2, Windows 8 | Comments (1)

Windows 8 client/server file traffic approaches DAS speed

March 3, 2012 – 12:08 am

Traditionally, client server file traffic has always been considered to be very slow, as compared to file access when the file is placed on Direct Attached Storage (DAS).

Note that clients as used in this particular blog apply to not just clients as in laptops, but also server to server communications where one of the servers acts as a client. For example, a laptop connects across the Internet to an IIS Server, and the IIS Server fetches some files from a file server to satisfy the client request.

Microsoft just posted a white paper showing some very interesting performance benchamrsk for file access over SMB2.2 when both client and server are running Windows 8. The paper can be found here

A one line summary of the paper could be “client/server file access speeds go from high twenty percent to almost parity with speed of Direct Attached Storage” ; and in particular from say 28% to 97%.

Note that the “client” used in the test had 48GB RAM, and while I admit that the test involved non cached I/O, so the extra RAM was not used for caching, it is still worth noting that this is not a typical client as in a laptop client. This is more like a server behaving as a client.

Nevertheless, this makes the client/server world more interesting, and also makes a compelling case for upgrading to Windows 8. Especially so when you can simultaneously upgrade all your servers e.g. SQL, IIS, and NAS file servers to be Windows 8. Upgrading just a single server does not help much, since in that case, the client is still an old client that does not speak the SMB 2.2 protocol.

Posted in Uncategorized | Comments (0)