Re : Filtering IDE

NTFSD
1

> Win32 only SAYS that this IO must be sector aligned.

> If the official documentation says so - then it is so.

That documentation is wrong.
> No, you’re just using the feauture which is unsupported and undocumented
and works by mere luck.

I understand what you are saying, but I disagree.

While I agree that I am using an undocumented and possibly unsupported
feature, it may or may not be mere luck that it works.
To suggest either is speculation. Unless you have some sort of proof.

We have 5 or 6 years of experience with this particular unsupported feature,
and it has worked in at least five completely different versions of Windows
OSes. The probability that it will continue to work thus seems pretty high.
It also works like this on the Mac. While that doesn’t really predict
anything about the next version of Windows, regarding whether or not this
undocumented behavior will continue, it does tend to insinuate that there is
no known hardware limitation that prohibits this from being possible.
Obviously, as it does work.

To then begin to guess as to whether or not this particular behavior will be
carried forward, we would need to understand why this limitation was made in
the first place. As I said, I do not suspect any hardware limitation being
the reason (with the exception being byte aligned IDE IO, which is my
concern). In Win95, the docs said the IO must be sector aligned, but instead
it needed to be page aligned. Why ? Because they used the page faulting
code to perform this disk IO. This was the reason; to reuse code that was
already there, due to tight product schedules (admittedly, this is
speculation, but seems to be true).

In all other Windows versions I have tested, there is no limitation, contrary
to the API docs. So the question then is why did they make that restriction
? For what purpose ? It could be due to a real issue, such as the page
alignment in Win95. Or it could be due to some perceived performance issue
(which I likewise have not found in my experience with this). Or it could be
due to ‘programmer paranoia’, or defensive programming (maybe they thought
some controllers could not perform IO to any arbitrary memory address).
Likewise, short of the IDE controllers, we have seen no examples of this. Or
maybe it was just a mistake. We simply don’t know why this restriction was
placed in the API docs. In order to truly know whether or not this behavior
will be ongoing, this is the question we need to answer. However, since we
have so far seen absolutely ZERO purpose for this, zero instances of failure,
in all of the systems we have run on in the last 6 years, I suggest that the
chances are very high that this will never change.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

2

>>>
The basic problem with PIO is that CPU is essentially stopped on the block
copy
instruction while it’s executing.
<<<

And this is probably why, in NT, the OS purposely fails odd byte IDE IO
requests. Otherwise, they would require PIO mode to be used, and the CPU
would sit and spin in a wait loop during the IO. As you know, this is
considered a very bad thing to do. But you can see that the NT drivers are
capable of performing byte aligned IO in PIO mode if you ‘fool’ the OS by
removing the ‘word alignment’ flag in the IDE related file system and driver
chain device objects.

>>
Really it’s the drive which determines the actual transfer time, as far as we
have seen, double buffering on IDE drives really offers no aggregate
advantage.
<<<

The issue I am concerned with here is not the speed of the transfer, nor
really even the speed of PIO vs DMA. It is only an issue of being able to do
it or not.
Our app currently requires disk IO to any arbitrary memory address. To
sector align everything would require a lot of changes. As I said, the OS
allows you to do this (non-cached IO to arbitrary addresses), with the single
exception currently being IDE IO to byte aligned addresses. If we would
allow the IO to go through the disk cache, this would not be an issue. The
cache manager would surely perform its IO to sector aligned buffers, and then
copy the data to the target buffer. We however do not want to do this. Our
app performs a lot of disk IO, and usually it is used only once. This amount
of disk data will obliterate any data that really ought to be kept in the
disk cache, such as program code or data, or directory sectors, and causes
the kernel’s memory management code to ‘go nuts’ trying to enlarge the disk
cache, due to the amount of data we are passing through there. This
eventually causes even our program code to get kicked out of RAM, to free
memory for the ever growing disk cache. It just thrashes the heck out of
things unnecessarily. So, we think it is best to bypass the cache entirely.
Non-cached IO is the only time you will see the IDE limitation on odd byte
memory addresses.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

3

> maybe it was just a mistake. We simply don’t know why this restriction
was

placed in the API docs.

My suggestion is that the support of this feature is hardware-dependent -
depends on your SCSI card and its driver, for instance. The SCSI cards and
drivers can easily not support the unaligned (not integral number of
sectors) IO on the disks.

As about the solution - writing a disk filter (not so complex) - will solve
the problem for you without bothering with IDE details (different chipsets
and controllers etc). This solution will also solve the problem on all
possible future SCSI controllers.

The Disk driver source is available in the DDK - you can use it to
understand how to write a filter.

Max

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com

4

>>>
As about the solution - writing a disk filter (not so complex) - will solve
the problem for you without bothering with IDE details (different chipsets
and controllers etc). This solution will also solve the problem on all
possible future SCSI controllers.

The Disk driver source is available in the DDK - you can use it to
understand how to write a filter.
<<<

Thanks, that sounds like a good idea.

You are currently subscribed to ntfsd as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntfsd-$subst(‘Recip.MemberIDChar’)@lists.osr.com