From: Mike Pittelkow [mikep@xiotech.com]
Sent: Wednesday, June 16, 1999 11:15 AM
To: Ntdev
Subject: [ntdev] Disk drivers and NT2k

This message is intended for those of you with storage device drivers that
are looking at moving to NT2000.

After a bunch of head scratching, I've found some interesting things about
NT2k that will probably be of use to those of use with monolithic storage
device drivers.

1) IoReadPartitionTable has changed in a rather strange way.  After
examining the MBR, it now issues a IOCTL_DISK_GET_PARTITION_INFO.
Consequently, if you call IoReadPartitionTable from your
IOCTL_DISK_GET_PARTITION_INFO handler, the system will eventually double
fault (which is impossible to find the source of after it happens).  Note
that in order to work with MSCS, you must return failure to this ioctl
(device_busy) if the device has been reserved by another initiator on the
bus.  The only way to tell this is to issue IO against the device. The way
I've seen this handled (and handle it myself) is to call
IoReadPartitionTable in resonse to this IOCTL, and if it succeeds, return
the appropriate data.  It's clean and easy to do. That won't work any more.
I have no idea why they changed this, it seems a little silly to me. You
need to gin up an IO now.

2) Creating \device\harddisk\partition0... is no longer sufficient to get
your devices seen by the disk administrator tool (it's an all new tool, if
you haven't seen it, with a whole new set of bugs)  Using winobj to look at
what the ide disk driver does (it's no longer part of the ddk), the
partition objects are now symbolic links to \device\harddiskvolumex, which
are in turn created by ftdisk.  The disk class driver (which is now used by
atdisk as well) creates objects that look like:  DP(1)0x7e00+0x7d040000+1
for partitions (this is the starting disk address, the ending disk address,
and device number), and DR0 for what used to be partition0 (I think).  The
symbolic links are created by the class driver.  There is no documentation
about any of this (there wasn't any before, but now it's significantly more
complex)

[steps on soap box]

From what I've seen so far, it appears that microsoft is making it extremely
difficult to create a monolithic device driver for storage devices.  This is
really too bad, because there are certain things you just plain can't do in
a miniport a) performance is 10-20% worse than a monolithic driver for the
same hardware, b) you can't do failover between two adapters c) you can't do
load balancing between two adapters d) queue depth (number of oustanding
asynchrounous requests) is severly limited (256 IO's vs. 512 on NT4).  I'll
be the first to admit a miniport is significantly easier to write, but
it's -not- the answer for every storage device.  There are plenty of
enterprise-class devices that it's just not appropriate for.

[steps off soap box]


Mike Pittelkow

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ To unsubscribe, send email to ntdev-request@atria.com with body
UNSUBSCRIBE (the subject is ignored). ]