Most operating systems today utilize software caching to increase disk performance. Often, this disk performance can be significantly enhanced by adding a hardware disk caching adapter. However, many caching adapters simply duplicate the caching algorithms of the operating system software. This may work well under DOS which typically does not use a software cache, but will not benefit operating systems like Unix or Novell which are already heavily cached in the software. In this case, duplicating the OS's caching algorithms in the disk adapter double-caches the same data. In fact, a software cache will always perform better on read hits than a hardware adapter cache since the software cache is closer to the application requesting the data.
DPT's caching adapters are specifically designed to work in environments like Unix or Novell which are already software cached. Although software caches are almost always beneficial, in larger, more heavily loaded systems, hardware caching offers a significant advantage when combined with the software cache in the operating system.
There are significant differences between the operating system's software cache, and the hardware cache in a SmartCache SCSI adapter. The primary purpose of the OS's software cache is to eliminate disk reads. If the data requested by the application program is found in the software cache, then a disk read is eliminated. A second strategy used in software caches (as in Unix and Novell NetWare) is to postpone writes to disk by holding the data in cache until a time when there is no disk activity. On the other hand, the primary purpose of a caching adapter is to find ways to increase the throughput for the disk I/O that does get through from the software.
Software write caching typically provides sufficient performance for lightly loaded systems with small numbers of users (six users or less), but will experience performance degradation in larger multi-user environments with heavier loading. This is due to a fundamental difference between read and writeSoftware write caching typically provides sufficient performance for lightly loaded systems with small numbers of users (six users or less), but will experience performance degradation in larger multi-user environments with heavier loading. This is due to a fundamental difference between read and write caching. Read caching eliminates disk accesses when cache hits occur, while write caching can only postpone disk write operations. Sooner or later, the data written to cache must be written to the disk drive. The software cache requires frequent periods of system idle time in which to -flush its I/O buffers to disk. This works well for lightly loaded systems which tend to have a lot of idle time.
As more users are added, periods of system idle time become less frequent and shorter. This causes two bad things to happen. First of all, as the system becomes more heavily loaded, the software cache begins to fill up with dirty sectors waiting to be written to disk. These sectors take up space in the software cache which could be used for read caching something that the software cache is much better at. Secondly, the software cache flushing operations begin to interfere with other system activity as more users are added to the system and less idle time results. In fact, when the system is under heavy loads and there is no idle time, the benefit of software write caching completely disappears.
When a hardware caching adapter is installed in the system, the operating system's cache buffers must still flush but the operation happens much more quickly. The hardware cache receives the flushed data in a fraction of the time it would take without hardware caching, and then proceeds to copy the data back to disk concurrently without interfering with other system activity. As an example, consider an operating system configured with one Megabyte of software cache which contains dirty data. With a 1 Kbyte record size and an average disk I/O time of 25ms, this flush operation would take 25 seconds. However, with a SmartCache adapter installed, the entire flush operation from the software cache would take approximately 1 second instead of 25 seconds. The adapter would then flush its cache to disk using its separate I/O bus, concurrently with other system activity.
In addition, the flush operation from the adapter will occur much faster, since the data is elevator sorted over a large number of sectors. When flushing dirty sectors from cache to disk, data is written to disk in order of increasing cylinder, head, and sector number, minimizing disk seeks and missed rotations, and thereby speeding up the entire operation. This feature, called Elevator Sorted Write-Back, eliminates much of the head thrashing commonly associated with disk-intensive operations. By elevator-sorting the sectors in cache, the average write access time to the drive may be reduced from the normal 25ms seek plus rotation time down to less than 10ms. A good analogy is a real elevator in a large, multi-story building. Consider how much slower the elevator would be if it went to the requested floors in the same order the buttons were pressed, instead of in elevator sorted order of increasing floor number. Without elevator sorting, you might be riding up and down all day before you got to the desired floor! One additional benefit of elevator sorting is that multiple short disk write operations can often be combined within the adapter cache into one larger write operation, thereby significantly reducing SCSI overhead.
Another way that average disk access time can be reduced is through Disk Read-Ahead Caching. Since disk data is often grouped in clumps of contiguous sectors on the disk, it is usually beneficial to continue to read sequential sectors into cache following a sector that has been requested by the computer. This is sometimes referred to as the principle of locality of reference. After each read command, the adapter checks its cache to see if the next eight sequential disk sectors are present. If not, when there is no activity on the SCSI bus, the adapter will request that the sectors be read from the SCSI drive's FIFO buffer. This operation occurs very quickly since once filled, the drive's FIFO buffer can be read at the full 10MB/sec Fast SCSI transfer rate.
In order for disk read-ahead to be effective in a multi-user environment, it is necessary to cache a large number of read-ahead sectors from many different areas of the disk. This is because multi-user and networking operating systems not only contain highly fragmented files, but also time-slice I/O requests from many different users or tasks. Data which has been cached by a read-ahead operation may not be accessed until many commands in the future when the same user or task has another chance to access the disk. This is why the SCSI drive's read-ahead FIFO, which can effectively store only a limited number of data segments, may provide acceptable performance in small systems, but must be augmented by the much larger cache on the adapter in larger multi-user environments. a limited number of data segments, may provide acceptable performance in small systems, but must be augmented by the much larger cache on the adapter in larger multi-user environments.
Hardware and Software Caching in Multi-User SystemsWhen building a multi-user system or fileserver, it is important to take into account the effect of the operating system's software cache on the disk subsystem. Since read hits from the operating system's software cache are serviced without requiring a disk access, but all writes get through to the disk sooner or later, the OS's cache acts as a read filter for the disk subsystem. As an example, an application program which generates three disk read operations for every disk write is said to have a 3:1 disk read to write ratio. However, if the OS's cache has a 66% read hit rate, then only one out of every three reads will get through to the disk subsystem. Thus the ratio of reads to writes as seen by the disk subsystem will be 1:1.
As more RAM is added to the system and the OS cache size is increased, more reads can be serviced from the software cache. However, all disk writes will still get through to the disk subsystem sooner or later. If, for example, the read hit ratio is increased, as a result of increasing system RAM, to 89%, the read to write ratio will now flip around to 1:3. Thus, as systems grow to contain more RAM and software caches become larger, write performance for the disk subsystem becomes critical. Because of this, adapters such as DPT's SmartCache and SmartRAID adapters are designed to increase disk write performance as a primary objective. Using these adapters can significantly improve overall system performance.