01-09-2014 03:47 PM
In this case a write is acknowledged to the caller only by writing to the cache device. The data is 'flushed' or written later to the primary storage. The rate of flushing and the algorithms used to determining what and when to flush can have a significant impact on offloading write requests from the primary storage.
This type of caching can significantly improve the performance of both writes and reads
FlashSoft supports this type of caching in its Windows and Linux products.
In this case a write is acknowledged to the caller only after data is written to both the cache and the primary device.
Both the writes are issued concurrently, but the caller gets an acknowledgement only after both the writes are completed.
In case the write to the cache device fails but the write to the primary device succeeds, the caller does not see the error because data is safely written to the primary storage.
In the reverse case, if the write to the primary storage fails but the write to the cache device succeeds, the write to the caller is marked as failure and the cached data is invalidated.
This type of caching can significantly improve the performance of reads.
FlashSoft supports this type of caching in all of its products (Windows, Linux and VMware).
Hope this helps.
01-14-2014 11:56 AM
Interesting. What kind of a performance difference do I get, whether I use writeback vs writethrough, for seomthing where both are available for use? Is there a preferred situation other than what I think my app needs? I heard writeback's always preferred, but then again, I'm not sure that applies to all situations.