A road named NoNameUno

Before, I continue on patterns of x64 assembly language, I've to take another pause. Yes you can see that the heading chanaged again...

I was stuck to dig out one problem we thought could be totally transient. This is where, simple, crisp design is so important when it comes to kernel software. Until we get our head wrap around it, we should always look for a way to decompose. The reason behind it is reasoning. Some transient problems are so hard, that disambiguation or rather make it consistently reproducible is very hard. 

I was trying to find this transient behavior, in a software component, that is somewhere in storage stack to enhance usuability. Since we can not trust the file system, I was using block level I/O to produce it and if possible make it deterministic. This was a requirement...

So I started out with opening a target disk, and write, read, and compare the data, synchronously & asychronously. For sync I/O we know, just do the I/O one sector at a time using the Windows API, for async we have few choices: Threads, Overlapped I/O etc. I picked overlapped I/O, and wait until all the payloads are written, then read, and compare...

How do we compare? And how do we make it as deterministics as possible? 

First one was not that tough, we had pre fabricated data basically a sequence starting from whereever we want, and each sector will have a specific pattern at double word buckets. First sector will have the first number, second sector will have the second number etc... So comparing is easy, from the buffers as well as looking at the raw disk.

For getting it to deterministic, repeatable reproduction of transient bug, I simply could not do that. I had payload with random number of sectors with random starting address, one sector at a time, multiple sectors at a time, clustered sectors etc and they can be used both for sync and async. For example, if I want clustered, it will break a payload of n sectors into 1, 2 , 4, 8, 16, ... remaining so that 1+2+4+...+ residue = n sectors, and you can do both sync, async among those payload.

While we found some other bugs that were easy to fix, one transient behavior was not solved. 

What I know, and it repeat itself is that testing alone is not the way to get out all the bugs of a component. Its a blend of design/design/design, simplify/simplify/simplify, structure/structure/structure the primitives... Then reason/reson/reason while the process of development goes on...

By the way, did I mention that I read the book: Science of Debugging. And I was carring a paper called "Needle in Haystack" and another monograph named "Stable Marriage and its relation to other ...".

The last two were to show respect and hope the family undestand why I'm working long hours when 90% of people around the small city are in bed :)

-pro

Note that it is a good testing mechanism, since the component under test, being a kernel module needed to be bombarded with random I/O at a high speed. Moreover, when I was doing just that, it was helping me debug both the target component, as well as the test component. It was helping each other, if you need more, I would be happy to explain later.