summaryrefslogtreecommitdiffstats
path: root/Documentation/device-mapper/cache.txt
diff options
context:
space:
mode:
authorJoe Thornber <ejt@redhat.com>2013-10-24 14:10:29 -0400
committerMike Snitzer <snitzer@redhat.com>2013-11-11 11:37:49 -0500
commit2ee57d587357f0d752af6c2e3e46434a74b1bee3 (patch)
treebecc2422f9ca836b4a6903051a64f3114b16eeb7 /Documentation/device-mapper/cache.txt
parentf494a9c6b1b6dd9a9f21bbb75d9210d478eeb498 (diff)
downloadtalos-op-linux-2ee57d587357f0d752af6c2e3e46434a74b1bee3.tar.gz
talos-op-linux-2ee57d587357f0d752af6c2e3e46434a74b1bee3.zip
dm cache: add passthrough mode
"Passthrough" is a dm-cache operating mode (like writethrough or writeback) which is intended to be used when the cache contents are not known to be coherent with the origin device. It behaves as follows: * All reads are served from the origin device (all reads miss the cache) * All writes are forwarded to the origin device; additionally, write hits cause cache block invalidates This mode decouples cache coherency checks from cache device creation, largely to avoid having to perform coherency checks while booting. Boot scripts can create cache devices in passthrough mode and put them into service (mount cached filesystems, for example) without having to worry about coherency. Coherency that exists is maintained, although the cache will gradually cool as writes take place. Later, applications can perform coherency checks, the nature of which will depend on the type of the underlying storage. If coherency can be verified, the cache device can be transitioned to writethrough or writeback mode while still warm; otherwise, the cache contents can be discarded prior to transitioning to the desired operating mode. Signed-off-by: Joe Thornber <ejt@redhat.com> Signed-off-by: Heinz Mauelshagen <heinzm@redhat.com> Signed-off-by: Morgan Mears <Morgan.Mears@netapp.com> Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Diffstat (limited to 'Documentation/device-mapper/cache.txt')
-rw-r--r--Documentation/device-mapper/cache.txt19
1 files changed, 16 insertions, 3 deletions
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt
index 33d45ee0b737..ff6639f72536 100644
--- a/Documentation/device-mapper/cache.txt
+++ b/Documentation/device-mapper/cache.txt
@@ -68,10 +68,11 @@ So large block sizes are bad because they waste cache space. And small
block sizes are bad because they increase the amount of metadata (both
in core and on disk).
-Writeback/writethrough
-----------------------
+Cache operating modes
+---------------------
-The cache has two modes, writeback and writethrough.
+The cache has three operating modes: writeback, writethrough and
+passthrough.
If writeback, the default, is selected then a write to a block that is
cached will go only to the cache and the block will be marked dirty in
@@ -81,6 +82,18 @@ If writethrough is selected then a write to a cached block will not
complete until it has hit both the origin and cache devices. Clean
blocks should remain clean.
+If passthrough is selected, useful when the cache contents are not known
+to be coherent with the origin device, then all reads are served from
+the origin device (all reads miss the cache) and all writes are
+forwarded to the origin device; additionally, write hits cause cache
+block invalidates. Passthrough mode allows a cache device to be
+activated without having to worry about coherency. Coherency that
+exists is maintained, although the cache will gradually cool as writes
+take place. If the coherency of the cache can later be verified, or
+established, the cache device can can be transitioned to writethrough or
+writeback mode while still warm. Otherwise, the cache contents can be
+discarded prior to transitioning to the desired operating mode.
+
A simple cleaner policy is provided, which will clean (write back) all
dirty blocks in a cache. Useful for decommissioning a cache.
OpenPOWER on IntegriCloud