Lines Matching +full:i +full:- +full:cache +full:- +full:block +full:- +full:size
8 This document describes a collection of device-mapper targets that
9 between them implement thin-provisioning and snapshots.
27 - Improve metadata resilience by storing metadata on a mirrored volume
28 but data on a non-mirrored one.
30 - Improve performance by storing the metadata on SSD.
40 dm-devel@redhat.com with details and we'll try our best to improve
46 a Red Hat distribution it is named 'device-mapper-persistent-data').
52 They use the dmsetup program to control the device-mapper driver
53 directly. End users will be advised to use a higher-level volume
57 -----------
60 It maps I/O linearly to the data volume and updates the metadata via
63 - Function calls from the thin targets
65 - Device-mapper 'messages' from userspace which control the creation of new
69 ------------------------------
78 are shared between thin devices (i.e. through snapshots). If you have
79 less sharing than average you'll need a larger-than-average metadata device.
87 The largest size supported is 16GB: If the device is larger,
91 ----------------------
96 wrong if it does not route I/O to exactly the same on-disk location as
100 -----------------------------
105 --table "0 20971520 thin-pool $metadata_dev $data_dev \
109 allocated at a time expressed in units of 512-byte sectors.
112 thin-pool is created. People primarily interested in thin provisioning
115 not zeroing newly-allocated data, a larger $data_block_size in the
118 $low_water_mark is expressed in blocks of size $data_block_size. If
132 Updating on-disk metadata
133 -------------------------
135 On-disk metadata is committed every time a FLUSH or FUA bio is written.
137 means the thin-provisioning target behaves like a physical disk that has
138 a volatile write cache. If power is lost you may lose some recent
151 transaction is aborted. Given that the pool will cache IO whose
158 -----------------
160 i) Creating a new thinly-provisioned volume.
162 To create a new thinly- provisioned volume you must send a message to an
167 Here '0' is an identifier for the volume, a 24-bit number. It's up
169 identifier is already in use, the message will fail with -EEXIST.
171 ii) Using a thinly-provisioned volume.
173 Thinly-provisioned volumes are activated using the 'thin' target::
175 dmsetup create thin --table "0 2097152 thin /dev/mapper/pool 0"
180 ------------------
182 i) Creating an internal snapshot.
196 Here '1' is the identifier for the volume, a 24-bit number. '0' is the
203 different from any other thinly-provisioned device and can be
207 device-mapper snapshots.)
209 Activate it exactly the same way as any other thinly-provisioned volume::
211 dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 1"
214 ------------------
217 thinly-provisioned volume. Any read to an unprovisioned area of the
222 thinly-provisioned volumes but have the base image on another device
229 i) Creating a snapshot of an external device
242 dmsetup create snap --table "0 2097152 thin /dev/mapper/pool 0 /dev/image"
248 ------------
262 'thin-pool' target
263 ------------------
265 i) Constructor
269 thin-pool <metadata dev> <data dev> <data block size (sectors)> \
275 Skip the zeroing of newly-provisioned blocks.
287 thin-pool has been created and first used in full
289 thin-pool creation.
294 Data block size must be between 64KB (128 sectors) and 1GB
305 needs_check|- metadata_low_watermark
308 A 64-bit number used by userspace to help synchronise with metadata
313 dm event will be sent to userspace. This event is edge-triggered and
319 'held' for userspace read access. '-' indicates there is no
329 drop into a read-only metadata mode in which no changes to
332 In serious cases where even a read-only mode is deemed unsafe
333 no further I/O will be permitted and the status will just
341 'no_space_timeout' expires. The 'no_space_timeout' dm-thin-pool
342 module parameter can be used to change this timeout -- it
349 thin-pool can be made fully operational again. '-' indicates
360 Create a new thinly-provisioned device.
361 <dev id> is an arbitrary unique 24-bit identifier chosen by
365 Create a new snapshot of another thinly-provisioned device.
366 <dev id> is an arbitrary unique 24-bit identifier chosen by
368 <origin id> is the identifier of the thinly-provisioned device
377 pool target. The thin-pool target offers to store an
378 arbitrary 64-bit transaction id and return it on the target's
381 compare-and-swap message.
387 get the root block associated with the metadata snapshot.
393 -------------
395 i) Constructor
402 the thin-pool device, e.g. /dev/mapper/my_pool or 253:0
409 an optional block device outside the pool to be treated as a
410 read-only snapshot origin: reads to unprovisioned areas of the
413 The pool doesn't store any size against the thin devices. If you