Chapter 5. Additional Topics 51
Use the writethroughcache parameter to force a different operation of the cache (on a
device or control unit level). The default operation uses a writeback cache technique.
Here is an example that uses all three options:
(resources definitions)
....
c3990A: cu 3390
interface local(1)
options ‘trackcachesize=150’
device(00) 3390-3 /usr/flexes/links/A3s1
device(01) 3390-3 /usr/flexes/links/B3s1 devopt ‘trackcachesize=5’
device(02) 3390-3 /usr/flexes/links/C3s1 devopt ‘trackcachesize=45’
device(03) 3390-3 /usr/flexes/links/D3s1 devopt ‘trackcachesize=30,writethroughcache’
device(04) 3390-1 OFFLINE devopt ‘trackcachesize=0’
end c3990A
This is a bit complex. The five devices defined will ask for (15 + 5 + 45 + 30 + 0 =) 95 tracks
of cache. (Device (00) does not specify a cache size and defaults to 15 tracks.) The control
unit definition specifies 150 tracks of cache. This is (150 - 95 =) 55 more tracks than needed
by individual device caches, and the 55 tracks will be a floating cache. The floating cache is
managed by internal FLEX-ES logic. Each 3390 track is about 57 KB, so the 150 tracks of
cache will require about 8.3 MB of Server storage.
Cache is normally allocated for an offline device, since you might perform a FLEX-ES mount
command to use the device. If you are certain you will not use the device (or you really want
no cache for some reason), you can specify a cache of zero tracks.
If you specify a control unit cache size of less than the sum of the individual device caches,
the specified control unit cache size is ignored.
FLEX-ES defaults to writeback cache operation. This allows the S/390 disk write channel
operation to complete when the data is in the FLEX-ES cache. The data will be flushed to the
Server disk at an indeterminate time in the future.
10
An exposure exists if the system fails
after a S/390 channel program thinks it completed a disk write, but the cache buffer has not
really been written to disk. In this case, the S/390 program may have wrong state
information. Such failures are extremely rare and the performance advantage of writeback is
so great that this default operation is almost always used.
A writethrough operation means that the S/390 channel operation for a disk write is not
complete until the data is actually written to the Server disk.
11
A copy of the data is retained in
the FLEX-ES cache for possible future use. A writethrough cache provides considerably
lower performance than a writeback cache, but it provides higher integrity. It might be
considered for a S/390 volume containing DB2 log data, for example.
If you have enough Server memory, you can specify large disk caches for better overall
system performance. There is obviously room for considerable tuning here, by manipulating
cache sizes at the device and control unit level. You can use the d ckdcachestats cuu
command to monitor cache effectiveness:
flexes> d ckdcachestats A80
ADDRESS READS WRITES CACHE HITS DEDICATED LINES LINES USED
A80 2880 182 1811 (97%) 15 15 (0%)
A81 2880 182 1811 (97%) 15 15 (0%)
A82 2880 182 1811 (97%) 15 15 (0%)
10
This should be a familiar concept. The typical UNIX operation involves writeback caches, where the disk cache
buffers are synched (flushed) to disk every 10 seconds or so.
11
This is not quite correct, because the RAID adapter also has a cache and the individual disk drives often have a
buffer that performs a temporary cache function. We ignore these points in the current discussion.