Dm-cache: Difference between revisions
→Cache policies: Language and clarity improvements |
ChadMiller (talk | contribs) No edit summary |
||
| Line 1: | Line 1: | ||
{{lowercase title}} |
{{lowercase title}} |
||
As part of the [[Linux kernel]], '''dm-cache''' is a [[device mapper]] target allowing creation of [[Hybrid drive#Dual-drive hybrid solutions|hybrid volumes]], written by Joe Thornber, Heinz Mauelshagen and Mike Snitzer. It allows one or more fast storage devices |
As part of the [[Linux kernel]], '''dm-cache''' is a [[device mapper]] target allowing creation of [[Hybrid drive#Dual-drive hybrid solutions|hybrid volumes]], written by Joe Thornber, Heinz Mauelshagen and Mike Snitzer. It allows one or more fast storage devices, such as flash-based [[solid-state drive]]s (SSDs), to act as a cache for one or more slower [[hard disk drive]]s. |
||
dm-cache uses three "block device" volumes—actual data, cache data, and [[metadata]])—to create one hybrid volume. Cache policies, in the form of separate modules, determine the way caching is performed. |
|||
==Overview== |
==Overview== |
||
In dm-cache, SSDs are used as a level of indirection in accessing rotational hard drives (HDDs). Since solid-state disks are much faster than rotational drives, dm-cache lets one keep a large, inexpensive data storage that has very fast access, meaning the best of both worlds of HDD and SSD.<ref>{{cite web |
|||
| url = http://www.linuxjournal.com/content/advanced-hard-drive-caching-techniques |
| url = http://www.linuxjournal.com/content/advanced-hard-drive-caching-techniques |
||
| title = Advanced Hard Drive Caching Techniques |
| title = Advanced Hard Drive Caching Techniques |
||
| Line 24: | Line 24: | ||
}}</ref> |
}}</ref> |
||
Cache policies, in form of separate modules, determine how dm-cache works internally; cache policies |
Cache policies, in form of separate modules, determine how dm-cache works internally; cache policies provide the [[algorithm]]s for selecting which blocks are promoted (moved from HDD to SSD), demoted (moved from SSD to HDD), kept in sync, cleaned etc.<ref name="kernel-cache">{{cite web |
||
| url = https://www.kernel.org/doc/Documentation/device-mapper/cache.txt |
| url = https://www.kernel.org/doc/Documentation/device-mapper/cache.txt |
||
| title = Documentation/device-mapper/cache.txt |
| title = Documentation/device-mapper/cache.txt |
||
| Line 33: | Line 33: | ||
}}</ref> |
}}</ref> |
||
When configured to use ''multiqueue'' cache policy (which is the default), dm-cache |
When configured to use ''multiqueue'' cache policy (which is the default), dm-cache uses SSDs for storing data associated with performed [[Random access|random reads and writes]], capitalizing on near-zero [[seek time]]s of SSDs and avoiding such [[Input/output|I/O]] operations as typical HDD performance bottlenecks. Data associated with sequential reads and writes is not cached on SSDs, in order to avoid [[cache invalidation]] during such operations; performance-wise, sequential I/O operations are much more suitable for HDDs, due to their mechanical nature. Not caching the sequential I/O also helps in extending lifetime of the SSDs used as caches.<ref name="kernel-cache-policies">{{cite web |
||
| url = https://www.kernel.org/doc/Documentation/device-mapper/cache-policies.txt |
| url = https://www.kernel.org/doc/Documentation/device-mapper/cache-policies.txt |
||
| title = Documentation/device-mapper/cache-policies.txt |
| title = Documentation/device-mapper/cache-policies.txt |
||
Revision as of 19:34, 15 January 2014
As part of the Linux kernel, dm-cache is a device mapper target allowing creation of hybrid volumes, written by Joe Thornber, Heinz Mauelshagen and Mike Snitzer. It allows one or more fast storage devices, such as flash-based solid-state drives (SSDs), to act as a cache for one or more slower hard disk drives.
dm-cache uses three "block device" volumes—actual data, cache data, and metadata)—to create one hybrid volume. Cache policies, in the form of separate modules, determine the way caching is performed.
Overview
In dm-cache, SSDs are used as a level of indirection in accessing rotational hard drives (HDDs). Since solid-state disks are much faster than rotational drives, dm-cache lets one keep a large, inexpensive data storage that has very fast access, meaning the best of both worlds of HDD and SSD.[1] Also, dm-cache can be used to improve performance and reduce the load of storage area networks.[2][3]
Cache policies, in form of separate modules, determine how dm-cache works internally; cache policies provide the algorithms for selecting which blocks are promoted (moved from HDD to SSD), demoted (moved from SSD to HDD), kept in sync, cleaned etc.[4]
When configured to use multiqueue cache policy (which is the default), dm-cache uses SSDs for storing data associated with performed random reads and writes, capitalizing on near-zero seek times of SSDs and avoiding such I/O operations as typical HDD performance bottlenecks. Data associated with sequential reads and writes is not cached on SSDs, in order to avoid cache invalidation during such operations; performance-wise, sequential I/O operations are much more suitable for HDDs, due to their mechanical nature. Not caching the sequential I/O also helps in extending lifetime of the SSDs used as caches.[5]
History
Another dm-cache project with similar goals was announced by Eric Van Hensbergen and Ming Zhao in 2006, as the result of an internship work at IBM.[6]
Later, Joe Thornber, Heinz Mauelshagen and Mike Snitzer got their own take on the concept, resulting in inclusion of dm-cache into the Linux kernel mainline; it was merged in kernel version 3.9, released on 28 April 2013.[4][7]
Design
Mapped virtual device (a hybrid volume) is created by specifying three physical devices:[5]
- origin device – provides slow primary storage (usually an HDD)
- cache device – provides a fast cache (usually an SSD)
- metadata device – records blocks placement and their dirty flags, as well as other internal data required by a policy (per-block hit counts etc.); such a device can not be shared between hybrid volumes, and it is recommended to be mirrored.
Block size, equaling to the size of a caching extent, is configurable only during the creation of a hybrid volume. Recommended sizes are 256–1024 KB, while they have to be multiples of 64. Having caching extents bigger than HDD sectors is a compromise between the size of metadata, and the possibility for wasting cache space. Having too small caching extents increases the metadata size, both in the metadata device and in kernel memory. Having too large metadata extents increases the amount of wasted cache space, due to whole extents being cached even in case of high hit rates only for some of their parts.[4][8]
Both write-back and write-through policies are supported for caching write operations. In case of the write-back policy, writes to cached blocks are going to the cache device only, with such blocks marked as dirty in the metadata. For the write-through policy, write requests are not returned as completed until data reaches both the origin and cache device, with no clean blocks becoming marked as dirty.[4] Rate of the data migration performed in both directions (data promotions and demotions) can be kept throttled down to a configured speed; that way, normal I/O to the origin and cache devices can be preserved.[4]
Decommissioning of a hybrid volume is performed by the cleaner policy (see the section below), which effectively flushes all dirty blocks from the cache device to the origin device.[5]
Cache policies
As of October 2013[update], two cache policies are distributed with the Linux kernel mainline:[5]
- multiqueue
- This policy has two sets of 16 queues; one set for entries waiting for the cache, and other set for entries already in the cache. Cache entries in the queues are aged based on their associated logical time. Selection of entries going into the cache is based on variable thresholds, and queue selection is based on the hit count of an entry. This policy aims to take different cache miss costs into account, and to adjust to varying load patterns automatically. Large, sequential I/O operations are left to be performed by the origin device, since HDDs tend to have good bandwidth; contiguous I/O operations are tracked internally, so they can be routed around the cache.
- cleaner
- This policy writes back all dirty blocks in a cache, so it can be decommissioned.
See also
References
- ^ Petros Koutoupis (2013-11-25). "Advanced Hard Drive Caching Techniques". linuxjournal.com. Retrieved 2013-12-02.
- ^ "dm-cache: Dynamic Block-level Storage Caching". Florida International University. Retrieved 2013-10-09.
- ^ Dulcardo Arteaga; Douglas Otstott; Ming Zhao. "Dynamic Block-level Cache Management for Cloud Computing Systems" (PDF). Florida International University. Retrieved 2013-12-02.
- ^ a b c d e Joe Thornber; Heinz Mauelshagen; Mike Snitzer. "Documentation/device-mapper/cache.txt". Linux kernel documentation. kernel.org. Retrieved 2013-10-07.
- ^ a b c d Joe Thornber; Heinz Mauelshagen; Mike Snitzer. "Documentation/device-mapper/cache-policies.txt". Linux kernel documentation. kernel.org. Retrieved 2013-10-07.
- ^ Eric Van Hensbergen; Ming Zhao (2006-11-28). "Dynamic Policy Disk Caching for Storage Networking" (PDF). IBM Research Report. IBM. Retrieved 2013-12-02.
- ^ "Linux 3.9". 1.3. SSD cache devices. kernelnewbies.org. 2013-04-28. Retrieved 2013-10-07.
- ^ Jake Edge (2013-05-01). "LSFMM: Caching – dm-cache and bcache". LWN.net. Retrieved 2013-10-07.