Disk and File I/O performance with ETW traces: Miscellany
Building upon the preliminary notes on analyzing Disk and File I/O performance with ETW traces, I’ll go into some more of the columns in the data.
The Priority column represents the I/O priority, where higher numbers are more urgent and lower numbers are less urgent. As a general rule, the system will attempt to satisfy higher priority I/O before low priority I/O, although it will let some lower priority I/O trickle through every so often to avoid starvation.
Normal priority is priority 3, and this is the priority for your typical application-initiated I/O. Applications can also issue I/O at priority zero, which makes it take a back seat to other I/O.¹ Search indexers use priority zero, for example, so that indexing operations do not interfere with normal I/O. Applications do not have access to I/O priority above 3. Those are reserved for system components.
Another interesting column is Source. Values for this column are Original, Prefetch, VolSnap, and Unknown.
Most I/O is marked as Original, which means basically that there’s nothing special going on. The I/O occurred because somebody explicitly asked for it.
If the I/O is marked Prefetch, then this is I/O was initiated by ReadyBoot, which should not be confused with ReadyBoost. (The similarity in the names is quite unfortunate.) ReadyBoot (without the s) prefetches data off the disk during boot based on its observations of what data was read from disk during previous boot sessions, hoping to stay one step ahead of the system’s actual I/O needs.
Another curiousity of ReadyBoot I/O is that it occurs below the file system level, so the file name in the events will be Unknown. You can use the Source column to identify that the I/O came from ReadyBoot.
I/O that is marked as VolSnap is initiated by volume snapshots. Volume snapshots capture the state of the disk at a moment in time. It would be expensive to make a copy of every byte of the disk when a snapshot is taken, so instead the snapshot is done lazily. The first time a write occurs to a part of the disk that was part of a snapshot, you actually get multiple operations:
- A read is issued to the disk to obtain the data that is about to be overwritten.
- A write is issued to the disk to write the old data to some other part of the disk for safekeeping.
- The original write request is allowed to go through.
The I/O operations resulting from volume snapshot lazy-copies are marked with the VolSnap source.
You will see Unknown as the source for Flush operations, since they apply to the disk as a whole, not to any individual file.
¹ Notice that disk priority is opposite of bug priority. For bug priority, lower numbers represent greater importance.
Light
Dark
7 comments
I look at all this cleverness and optimisation and beautifully layered driver model, and I feel sad because it’s all wasted. On top of all this excellence, Microsoft is encouraging people to run Teams, a product so bad, I don’t actually think it matters what OS it runs on.
I will never understand why people think they must vent their grievances about completely off topic products that Raymond doesn’t even work on on this blog. It’s also usually accompanied with amazing amounts of hyperbole.
To stay on topic I always wondered what values the source column could have. It’s nice that Raymond explains them here, but some better official documentation would be very much welcome in that area.
I kinda like this “word merchant” actually. At least for me, I like hearing some funny words every now and then. (Also I don’t think this is the only instance in which people have jeered at Microsoft Teams in the comment sections of this blog.)
Hmm… Never had noticed the ReadyBoot and ReadyBoost similarity. I usually don’t remember Microsoft brand names when I don’t buy or actively use them.
ReadyBoot is the logical prefetcher. ReadyBoost, however, is the better-known part of Superfetch.
Physical disk sectors are supposed to be intellectual property, but I guess they must map to expected sectors to avoid defying physics. At any rate, I’d rather Windows put my data on the most reliable sectors instead of the fastest. Also all things being equal, there was a song about spinning records or some such that I can’t remember anymore.
Well, most people do not consider operating system files to be their most valuable data, so I guess Microsoft has a point on that.
Once upon a time, when SSD still had low write cycles was considered not-to-be-trusted because of wearout problem, the “best practice” of installing SQL server is to put the OS on SSD and put the data on standalone SAS array.
Btw, most SAS/SCSI/Raid controller also have pre-fetch logic on the firmware to improve read performance. I wonder if Windows will detect and adjust the prefetch size on those systems.