StableBit DrivePool Q521955 - Revision history

Alex: /* StableBit DrivePool and Fast I/O */

2014-06-18T04:00:50Z

StableBit DrivePool and Fast I/O

Alex: /* Fast I/O */

2014-06-18T03:55:45Z

Fast I/O

Alex: /* IRPs are Unnecessary */

2014-06-18T03:38:29Z

IRPs are Unnecessary

Alex: /* Read-ahead Cache */

2014-06-18T03:36:25Z

Read-ahead Cache

Alex: /* Read-ahead Cache */

2014-06-18T03:15:28Z

Read-ahead Cache

Alex: /* I/O Request Packets IRPs */

2014-06-18T02:59:35Z

I/O Request Packets IRPs

Alex: /* What is Fat I/O */

2014-06-18T02:56:51Z

What is Fat I/O

Alex: /* Answer */

2014-06-18T02:51:47Z

Answer

Alex: /* StableBit DrivePool and Fast I/O */

2014-06-18T00:24:30Z

StableBit DrivePool and Fast I/O

Alex at 00:19, 18 June 2014

2014-06-18T00:19:03Z

← Older revision		Revision as of 04:00, 18 June 2014
Line 56:		Line 56:
	* Network I/O boost is enabled (normally only read Fast I/O is disabled, but can be changed in .config).		* Network I/O boost is enabled (normally only read Fast I/O is disabled, but can be changed in .config).

−	For the most part, StableBit DrivePool rejects Fast I/O requests ~~because~~ additional processing is required for an I/O request.	+	For the most part, StableBit DrivePool rejects Fast I/O requests when additional processing is required for an I/O request.

@@ Line 34: / Line 34: @@
 ===Fast I/O===
-This is what the original designer of the Windows kernel were thinking and this is where Fast I/O comes in. Fast I/O gets rid of the whole concept of IRPs and allows the application sending the read request to simply ask the file system for some data, without creating any IRPs. It can optionally state that if the data is not cached, the Fast I/O request should be aborted immediately (presumably because the application intends to create and send an IRP for that data shortly after).
+This is what the original designers of the Windows kernel were thinking and this is where Fast I/O comes in. Fast I/O gets rid of the whole concept of IRPs and allows the application sending the read request to simply ask the file system for some data, without creating any IRPs. It can optionally state that if the data is not cached, the Fast I/O request should be aborted immediately (presumably because the application intends to create and send an IRP for that data shortly after).
 For a Fast I/O write request, the file system puts the data to be written in the memory cache (to be written at a later time). If the memory cache has a lot of data waiting to be written to the disk, then the caller can optionally ask Fast I/O to fail immediately instead of waiting for some of that data to be written to disk and the cache to be freed up (again, presumably because the application intends to send a write IRP shortly after).

@@ Line 31: / Line 31: @@
 This is all sounding great, we have IRPs, which are a powerful mechanism for managing multiple I/O requests, and caching speeds up the whole process.
-But wait, let's think about the typical file copying process when caching is in use. For the source file, if caching is working properly, there is a good chance that the data being requested had already been read in and is in memory. Thus, a request for that data sent to the file system should be completed immediately. If that's the case then the chief advantage that IRPs provide, asynchronous I/O (I.E. having the ability to send another IRP while the first one is processing), is unnecessary. That also means that the whole process of creating an IRP and managing those IRPs is also unnecessary.
+But wait, let's think about the typical file copying process when caching is in use. For the source file, if caching is working properly, there is a good chance that the data being requested has already been read in, and is in memory. Thus, a request for that data sent to the file system should be completed immediately. If that's the case then the chief advantage that IRPs provide, asynchronous I/O (I.E. having the ability to send another IRP while the first one is processing), is unnecessary. That also means that the whole process of creating an IRP and managing those IRPs is also unnecessary.
 ===Fast I/O===

@@ Line 21: / Line 21: @@
 ====Read-ahead Cache====
-But think about it, the file system can get a bit smarter and realize that we're reading the whole file one chunk at a time. So, after a chunk is read, the file system can start to read the next chunk of data, even before it receives the IRP. Once the next IRP arrives, it can simply complete it right away because the data has already been read from the disk and is already in memory. This is called read-ahead caching and happens all the time in Windows.
+But think about it, the file system can get a bit smarter and realize that we're reading the whole file one chunk at a time. So, after a chunk is read, the file system can start to read the next chunk of data, even before it receives the next IRP. Once the next IRP arrives, it can simply complete it right away because the data has already been read from the disk and is already in memory. This is called read-ahead caching and happens all the time in Windows.
 ====Write-behind Cache====

@@ Line 21: / Line 21: @@
 ====Read-ahead Cache====
-But think about it, the file system can get a bit smarter and realize that we're reading the whole file one chunk at a time. So, after the last chunk is read the file system can start to read the next chunk of data, even before it receives the IRP. Once the next IRP arrives, it can simply complete it right away because the data has already been read from the disk and is already in memory. This is called read-ahead caching and happens all the time in Windows.
+But think about it, the file system can get a bit smarter and realize that we're reading the whole file one chunk at a time. So, after a chunk is read, the file system can start to read the next chunk of data, even before it receives the IRP. Once the next IRP arrives, it can simply complete it right away because the data has already been read from the disk and is already in memory. This is called read-ahead caching and happens all the time in Windows.
 ====Write-behind Cache====

@@ Line 8: / Line 8: @@
 In short, Fast I/O bypasses the normal I/O processing model in the Windows kernel and opts for a faster, but perhaps less flexible approach. It is part of the core architecture of Windows.
-=== I/O Request Packets IRPs ===
+=== I/O Request Packets ===
 In order to understand how Fast I/O differs from the "normal" I/O model, you'll have to have some idea of what the normal model is. Normally in Windows every I/O request is represented by something called an ''I/O Request Packet'', or IRP. For every I/O request, such as a read or a write on a volume, an IRP is created and sent to the file system mounted over that volume in order to satisfy the I/O request. The file system then performs additional processing necessary to complete the I/O request, such as reading data from one or more disks, and then ''completes'' the IRP.

@@ Line 5: / Line 5: @@
 Fast I/O is a technical term that describes how I/O is processed in the Windows kernel, and you don't really need to understand what it is in order to use StableBit DrivePool effectively. But for those of you who are interested in this concept, this article will give you a brief description of what it is and why it's important (or perhaps not so important).
-===What is Fat I/O===
+===What is Fast I/O===
 In short, Fast I/O bypasses the normal I/O processing model in the Windows kernel and opts for a faster, but perhaps less flexible approach. It is part of the core architecture of Windows.

@@ Line 3: / Line 3: @@
 ==Answer==
-Fast I/O is a technical term that describes how I/O is processed in the Windows kernel, and no one really needs to understand what it is in order to use StableBit DrivePool effectively. But for those of you who are interested in this concept, this article will give you a brief description of what it is and why it's important (or perhaps not so important).
+Fast I/O is a technical term that describes how I/O is processed in the Windows kernel, and you don't really need to understand what it is in order to use StableBit DrivePool effectively. But for those of you who are interested in this concept, this article will give you a brief description of what it is and why it's important (or perhaps not so important).
 ===What is Fat I/O===

← Older revision		Revision as of 00:24, 18 June 2014
Line 50:		Line 50:

	===StableBit DrivePool and Fast I/O===		===StableBit DrivePool and Fast I/O===
−	To be ~~continued~~...	+	StableBit DrivePool explicitly rejects Fast I/O requests under these circumstances:
		+	* If explicitly disabled in the .config file.
		+	* If the file is a CoveFS metadata stream.
		+	* If caching was not initiated on the file (I.E. non-cached I/O was requested).
		+	* Network I/O boost is enabled (normally only read Fast I/O is disabled, but can be changed in .config).
		+
		+	For the most part, StableBit DrivePool rejects Fast I/O requests because additional processing is required for an I/O request.