Samsung SpinPoint M8, Руководство по эксплуатации продукта

Страница: 39 / 83

Spinpoint M8 Product Manual REV 2.7
33
disk requests are sequential. It takes microseconds rather than milliseconds to retrieve this cached data. Thus Read
Caching can provide substantial time savings during at least half of all disk requests. For example, Read Caching
could save most of the disk transaction time by eliminating the seek and rotational latency delays that prominently
dominate the typical disk transaction.
Read Caching operates by continuing to fill its cache memory with adjacent data after transferring data requested
by the host. Unlike a non-caching controller, the 88i6526 Interface Controller continues a read operation after
the requested data has been transferred to the host system. This read operation terminates after a programmed
amount of subsequent data has been read into the cache memory.
The cache memory consists of a sync DRAM buffer allocated to hold the data. It can be directly accessed
by the host by means of read and write commands. The unit of data stored is the logical block, or a multiple of the
512-byte sector. Therefore, all accesses to cache memory must be in multiples of the sector size. The following
commands empty the cache:

IDENTIFY DRIVE (ECh)

FORMAT TRACK (50h)

EXECUTE DRIVE DIAGNOSTIC (90h)

READ LONG (23h)

WRITE VERIFY (3Ch)

INITIALIZE DEVICE PARAMETER (91h)

SLEEP (99h, E6h)

STANDBY IMMEDIATELY (94h, E0h)

READ BUFFER (E4h)

WRITE BUFFER (E8h)

WRITE SAME (E9h)
5.5.2 Write Caching
Write caching improves both single and multi-sector write performance by reducing delays introduced by
rotational latency. When the drive writes a pattern of multiple sequential data, it stores the data to a cache
buffer and immediately sends a COMMAND COMPLETE message to the host before it writes the data to the
disk.
The data is then written collectively to the drive thereby minimizing the disk seeking operation. Data is
held in cache no longer than the maximum seek time plus rotational latency. Host retries must be enabled
for Write Caching to be active.
If the data request is random, the data of the previous command is written to the disk before COMMAND
COMPLETE is posted for the current command. Read commands work similarly. The previous write is
allowed to finish before the read operation starts.
If a defective sector is found during a write, the sector is automatically relocated before the write
occurs. This ensures that cached data that already has been reported as written successfully gets written,
even if an error should occur.
If the sector is not automatically relocated, the drive drops out of write caching and reports the error as an ID
Not Found. If the write command is still active on the AT interface, the error is reported during that command.
Otherwise, it is reported on the next command.