This message is from the T13 list server.
Some comments on the NV cache proposal.
My major comment is this thing is that it makes no sense. If an OS needs
a NV storage area in a computer system that NV storage should be part of
the system (motherboard) and not part of each drive that may be present.
Adding NV storage to a drive is like adding isochronous data transfer to
a drive (aka the AV commands) - it is adding a feature and hardware to a
drive and this is the most expensive method to do this, the most
difficult to maintain method and the least effective method to achieve
the desired results.
A host that would take advantage of this new hardware feature would
also benefit from extended product life and improved shock
resistance.
This statement in the Introduction really makes no sense at all - who
are we trying to kid here - extended product life - extended product
life of what - the OS? And I have doubts about any benefit to shock
resistance.
It is not likely that the Pinned and Un-Pinned areas of the NV Cache
will be contiguous.
If the operation of the NV cache is internal/private to the drive what
does contiguous location in the NV cache have to do with anything?
The addition of this new feature would never permit a drive to
satisfy a read of an LBA with anything but the value that was last
written to that LBA.
-and-
LBA in the NV Cache has a single attribute which determines if the
LBA is managed by the Host or the drive.
These statements are inconsistent. If a drive shall never return data
except for the data last written to a sector then the drive is always
managing the status of every sector in the NV cache and on its media.
The host is only offering a list of LBA that are also maintained in the
NV cache.
Since it is possible to Add an LBA to the NV Cache Pinned Set without
requiring the LBA’s sector data to be added to the NV Cache, there
will be times that the NV Cache will contain LBAs whose sector data
is incorrect. Likewise since the NV Cache holds writes while the disk
is spun down there will be times that the disk will contain LBAs
whose sector data is incorrect.
Absolutely wonderful. Great idea. Lets make ATA even more unreliable.
If a drive has an active/defined but disabled/nonoperational NV cache
and some other s/w is booted that does not know about the NV cache and
does not enable the NV cache but that s/w writes to sectors that are in
the NV cache, what happens when the original NV cache aware s/w is
booted and enables the NV cache? If the drive must never return
old/invalid data then a drive that has an NV cache must have it enabled
all the time. Why have NV cache enable/disable SET FEATURE subcommands?
Word TBD4 bits 0-11 specifies the maximum sustained transfer speed of
the device’s NV Cache during a read in megabytes per second.
What about the write speed? If the NV cache is flash memory then any
writes to the drive could be slowed down to the write speed of the flash
memory. Doesn't sound very good to me.
> command descriptions
The command descriptions for the commands that transfer data do not
describe the format of the data that is transferred.
Last comment for now... I've seen lots of caching algorithms but this
one has to be one of the most repugnant I've ever seen. I can see no
value to it and only see a greater chance that ATA would become more
unreliable by creating even more data integrity problems, even more
hardware and firmware bugs in drives, and add cost to a drive. Adding
cost should get this killed since most disk drive vendors would need to
purchase NV memory wholesale from memory vendors. If this NV cache is
really needed by Microsoft to fix some problem in their OS design then
that NV memory should be part of the system's memory components - where
there is some chance it could be added to a system at a cost effective
price - inside a disk drive must be the most cost ineffective way to do
this. I'm curious... Did Intel reject the idea of adding this to a
motherboard? Is that why this proposal is now at T13?
Hale
--
++ Hale Landis ++ www.ata-atapi.com ++
