linux.git/Documentation/device-mapper/cache.txt, branch v3.13

dm cache: update Documentation for invalidate_cblocks's range syntax

2013-12-10T21:35:15+00:00

The cache target's invalidate_cblocks message allows cache block
(cblock) ranges to be expressed with: -

The range's  value is "one past the end", so the range
includes  through -1.

Signed-off-by: Mike Snitzer 
Acked-by: Joe Thornber

dm cache: resolve small nits and improve Documentation

2013-11-12T18:11:09+00:00

Document passthrough mode, cache shrinking, and cache invalidation.
Also, use strcasecmp() and hlist_unhashed().

Reported-by: Alasdair G Kergon 
Signed-off-by: Mike Snitzer

dm cache: add cache block invalidation support

2013-11-11T16:37:51+00:00

Cache block invalidation is removing an entry from the cache without
writing it back.  Cache blocks can be invalidated via the
'invalidate_cblocks' message, which takes an arbitrary number of cblock
ranges:
   invalidate_cblocks [|-]*

E.g.
   dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789

Signed-off-by: Joe Thornber 
Signed-off-by: Mike Snitzer

dm cache: add passthrough mode

2013-11-11T16:37:49+00:00

"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 
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Morgan Mears 
Signed-off-by: Mike Snitzer

dm cache: add data block size limits to code and Documentation

2013-08-23T13:02:13+00:00

Place upper bound on the cache's data block size (1GB).

Inform users that the data block size can't be any arbitrary number,
i.e. its value must be between 32KB and 1GB.  Also, it should be a
multiple of 32KB.

Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Acked-by: Joe Thornber

dm cache: document metadata device is exclussive to a cache

2013-08-23T13:02:13+00:00

A cache's metadata device may not be shared by multiple cache devices.

Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon 
Acked-by: Joe Thornber

doc: fix misspellings with 'codespell' tool

2013-05-28T10:02:12+00:00

Signed-off-by: Anatol Pomozov 
Signed-off-by: Jiri Kosina

dm: add cache target

2013-03-01T22:45:51+00:00

Add a target that allows a fast device such as an SSD to be used as a
cache for a slower device such as a disk.

A plug-in architecture was chosen so that the decisions about which data
to migrate and when are delegated to interchangeable tunable policy
modules.  The first general purpose module we have developed, called
"mq" (multiqueue), follows in the next patch.  Other modules are
under development.

Signed-off-by: Joe Thornber 
Signed-off-by: Heinz Mauelshagen 
Signed-off-by: Mike Snitzer 
Signed-off-by: Alasdair G Kergon