In my original design, NZFS consisted of a minimal kernel mode driver with the bulk of the processing happening in user mode.
The motivations were quite simple: kernel mode development is a major pain in the ass and everywhere else! So, avoid it! :(

On top of being very restricted resource wise, one must entirely obey these guidelines:;EN-US;Q186775&
Not only bugs in kernel mode executions are unforgiving (blue screen of death anyone?), they are also non-obvious (get ready to call WinDbg your new best friend and time consuming’ly so).

Unless you are a hardcore and lifelong dedicated kernel mode developer, the constraints and learning curve are far too steep.
My only salvation in this whole initiative is that I have been dabbling in kernel mode development ever since I started FlexRAID. This has given me enough time to slowly get comfortable with this very niche type of programming.

In any case, I really wanted to minimize my kernel mode execution. The rewards were obvious: less pain and less bugs.
Moreover, most of my libraries are user mode libraries and porting them to the kernel means some serious refactoring.

I thought hard and long and fought myself between “easy street” and the “right way”.
Yet, as Spike Lee would say, “Do the Right Thing” nudged me along the side of the “right way”.
And so I did and ported everything into the kernel. :)

Obviously, there are many advantages to going 100% kernel mode, but I will leave those points for another post.
The key point in all this is that development of NZFS will take much longer given the now longer debugging and testing time it requires.

Nevertheless, I have made great progress as everything has been successfully ported to the kernel.
Simple NZFS volumes work nicely including RAID 0 and mirrored volumes. I will be testing parity based RAID volumes this weekend.
If all works out, the next step will be implementing the management and maintenance components.


Leave a Reply

Set your Twitter account name in your settings to use the TwitterBar Section.