mirror of https://github.com/Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
116 lines
3.4 KiB
116 lines
3.4 KiB
====== |
|
dm-era |
|
====== |
|
|
|
Introduction |
|
============ |
|
|
|
dm-era is a target that behaves similar to the linear target. In |
|
addition it keeps track of which blocks were written within a user |
|
defined period of time called an 'era'. Each era target instance |
|
maintains the current era as a monotonically increasing 32-bit |
|
counter. |
|
|
|
Use cases include tracking changed blocks for backup software, and |
|
partially invalidating the contents of a cache to restore cache |
|
coherency after rolling back a vendor snapshot. |
|
|
|
Constructor |
|
=========== |
|
|
|
era <metadata dev> <origin dev> <block size> |
|
|
|
================ ====================================================== |
|
metadata dev fast device holding the persistent metadata |
|
origin dev device holding data blocks that may change |
|
block size block size of origin data device, granularity that is |
|
tracked by the target |
|
================ ====================================================== |
|
|
|
Messages |
|
======== |
|
|
|
None of the dm messages take any arguments. |
|
|
|
checkpoint |
|
---------- |
|
|
|
Possibly move to a new era. You shouldn't assume the era has |
|
incremented. After sending this message, you should check the |
|
current era via the status line. |
|
|
|
take_metadata_snap |
|
------------------ |
|
|
|
Create a clone of the metadata, to allow a userland process to read it. |
|
|
|
drop_metadata_snap |
|
------------------ |
|
|
|
Drop the metadata snapshot. |
|
|
|
Status |
|
====== |
|
|
|
<metadata block size> <#used metadata blocks>/<#total metadata blocks> |
|
<current era> <held metadata root | '-'> |
|
|
|
========================= ============================================== |
|
metadata block size Fixed block size for each metadata block in |
|
sectors |
|
#used metadata blocks Number of metadata blocks used |
|
#total metadata blocks Total number of metadata blocks |
|
current era The current era |
|
held metadata root The location, in blocks, of the metadata root |
|
that has been 'held' for userspace read |
|
access. '-' indicates there is no held root |
|
========================= ============================================== |
|
|
|
Detailed use case |
|
================= |
|
|
|
The scenario of invalidating a cache when rolling back a vendor |
|
snapshot was the primary use case when developing this target: |
|
|
|
Taking a vendor snapshot |
|
------------------------ |
|
|
|
- Send a checkpoint message to the era target |
|
- Make a note of the current era in its status line |
|
- Take vendor snapshot (the era and snapshot should be forever |
|
associated now). |
|
|
|
Rolling back to an vendor snapshot |
|
---------------------------------- |
|
|
|
- Cache enters passthrough mode (see: dm-cache's docs in cache.txt) |
|
- Rollback vendor storage |
|
- Take metadata snapshot |
|
- Ascertain which blocks have been written since the snapshot was taken |
|
by checking each block's era |
|
- Invalidate those blocks in the caching software |
|
- Cache returns to writeback/writethrough mode |
|
|
|
Memory usage |
|
============ |
|
|
|
The target uses a bitset to record writes in the current era. It also |
|
has a spare bitset ready for switching over to a new era. Other than |
|
that it uses a few 4k blocks for updating metadata:: |
|
|
|
(4 * nr_blocks) bytes + buffers |
|
|
|
Resilience |
|
========== |
|
|
|
Metadata is updated on disk before a write to a previously unwritten |
|
block is performed. As such dm-era should not be effected by a hard |
|
crash such as power failure. |
|
|
|
Userland tools |
|
============== |
|
|
|
Userland tools are found in the increasingly poorly named |
|
thin-provisioning-tools project: |
|
|
|
https://github.com/jthornber/thin-provisioning-tools
|
|
|