Caching in clariion

  

       From the chart above, the amount of Cache that a Clariion contains is based on the model.

Read Caching

First, we will describe the process of when a host issues a request for data from the Clariion.

1.The host issues the request for data to the Storage Processor that owns the LUN. If that data is sitting in Cache on the Storage Processor,

2.The SP sends the data back to the host.

If however, the data is not in Cache, the Storage Processor must go to disk now to retrieve the data. (Step 1 ½ ). It reads the data from the LUN into Read Cache of the owning Storage Processor. (Step 1 ¾ ) before it sends the data to the host.

Write Caching

1.The host writes a block of data to the LUN’s owning Storage Processor.

2.The Storage Processor MIRRORs that data to the other Storage Processor.

3.The owning Storage Processor then sends the Acknowledgement back to the host, that the   data is “on disk.”

4.At a later time, the data will be “flushed” from Cache on the SP out to the LUN.

         Why does Write Cache MIRROR the data to the other Storage Processor before it sends the acknowledgement back to the host?

         This is done to ensure that both Storage Processors have the data in Cache in the event of an SP failure. Let’s say that the owning Storage Processor crashed (again, never happens). If that data was not written to the other Storage Processor’s Cache, that data would be lost. But, because it was written to the other SP Cache, that Storage Processor can now write that data out to the LUN.

         This MIRRORing of Write Cache is done through the CMI (Clariion Messaging Interface) Channel which lives on the Clariion.