{"id":5236,"date":"2017-04-24T09:17:40","date_gmt":"2017-04-24T07:17:40","guid":{"rendered":"https:\/\/new.cloudandheat.com\/block-level-data-tracking-using-davice-mappers-dm-era\/"},"modified":"2023-03-08T16:04:32","modified_gmt":"2023-03-08T15:04:32","slug":"block-level-data-tracking-using-davice-mappers-dm-era","status":"publish","type":"post","link":"https:\/\/www.cloudandheat.com\/en\/block-level-data-tracking-using-davice-mappers-dm-era\/","title":{"rendered":"Block-level data tracking using device mapper's dm-era"},"content":{"rendered":"

 <\/p>\n

This blog post will be a full tutorial about the usage of the \u201cera\u201d target of device mapper, also known as \u201cdm-era\u201d. It provides a step by step walkthrough for setting up the device mapper mappings and parsing the resulting metadata.<\/span><\/p>\n

 <\/p>\n

Content<\/h2>\n

Device Mapper Mappings<\/a><\/p>\n

Creating a playground VM using Vagrant<\/a><\/p>\n

Device Mapper Setup<\/a><\/p>\n

Determining Metadata size<\/a><\/p>\n

Using the dm-era<\/a><\/p>\n

Conclusion<\/a><\/p>\n

Acknowledgments<\/a><\/p>\n

 <\/p>\n

The \u201cera\u201d target of device mapper can be quite powerful when looking for live tracking of changed blocks on an arbitrary block device, no matter if physical or logical. Since it is a low-level device mapper target it supports raw\/physical block devices, device mapper targets as well as LVM volumes to keep track of.<\/span><\/p>\n

The dm-era target has been integral part of the Linux kernel since version 3.15. So it has been around for quite a while already, however, documentation is still astonishingly sparse. Essentially, I could only come up with three results while searching the web: the <\/span>official kernel docs<\/span><\/a> [1]<\/sup>, a <\/span>blog post by Rackcorp<\/span><\/a> [2]<\/sup>, and a <\/span>Gentoo wiki entry<\/span><\/a> [3]<\/sup>.
\nSince the kernel docs and the Gentoo wiki entry only provide the most basic information without full usage examples, the Rackspace blog entry is a more elaborated guide \u2013 but not without its flaws.<\/span><\/p>\n

The essential part about working with device mapper is to understand that the basic size unit used is sectors. Whenever specifying a size for mappings, keep in mind it\u2019s at sector level. Usually a sector is defined as 512 bytes.<\/span><\/p>\n

 <\/p>\n

Device Mapper Mappings<\/h2>\n

 <\/p>\n

The basic modus operandi of device mapper is to apply mappings to block devices. That means you will be building layers above block devices, creating new block devices in the process. This is achieved by \u201ctargets\u201d, which are modules for device mapper that provide a particular mapping functionality.
\nThe most basic target is \u201clinear\u201d, which means the resulting block device will be a mapping to one or more linear sections of one or more other block devices. This way it\u2019s possible to logically merge two block devices into one or to split one up into several (like logical partitions). Please refer to one of the plenty documentations or tutorials about the \u201clinear\u201d device mapper target to learn more.
\nIn this guide we will be focussing on the cooperation of \u201clinear\u201d and \u201cera\u201d device mapper targets to track changed blocks on a block device in realtime.<\/span><\/p>\n

The Era Target<\/span><\/h3>\n

The \u201cera\u201d target behaves similar to the \u201clinear\u201d target but additionally it writes metadata to a separate block device which is used to keep track of changed blocks on the origin block device. To be precise, the \u201cera\u201d target keeps track of changed blocks within a specific period of time, called an era. This era is a monotonically increasing counter and each block has an era associated to it, where it was last updated in. The era can be increased by command and is also automatically increased when grabbing a metadata snapshot to inspect changed blocks. This allows tracking changed blocks between those snapshots and can be used for a variety of use cases, e.g. incremental backup or replication strategies.
\nOther than that, the \u201cera\u201d target does an identity mapping to the underlying origin block device, normally chosen the same size as its origin.<\/span><\/p>\n

 <\/p>\n

Creating a playground VM using Vagrant<\/h2>\n

For this tutorial, we will be setting up a virtual machine (VM) with 2 additional drives using VirtualBox. We will be using the VM and the drives to create a sample dm-era setup, so you can easily recreate an identical setup and follow the instructions step-by-step. To make things quick and easy regarding the VM setup, we will be using Vagrant to automatically set this up. Place the following file named \u201cVagrantfile\u201d into a (preferably empty) folder of your choice:<\/p>\n

 <\/p>\n

extdisk1 = '.\/extdisk1.vdi'\nextdisk2 = '.\/extdisk2.vdi'\nVagrant.configure(\"2\") do |config|\nconfig.vm.define \"alice\" do |alice|\nalice.vm.provider \"virtualbox\" do |vbox|\nvbox.name = \"dm-era-testvm\"\nunless File.exist?(extdisk1)\nvbox.customize ['createhd', '--filename', extdisk1, '--size', 256]\nvbox.customize ['storageattach', :id, '--storagectl', 'SATA Controller', '--port', 1, '--device', 0, '--type', 'hdd', '--medium', extdisk1]\nend\nunless File.exist?(extdisk2)\nvbox.customize ['createhd', '--filename', extdisk2, '--size', 256]\nvbox.customize ['storageattach', :id, '--storagectl', 'SATA Controller', '--port', 2, '--device', 0, '--type', 'hdd', '--medium', extdisk2]\nend\nend\nalice.vm.box = \"bento\/ubuntu-16.04\"\nalice.vm.hostname = \"alice\"\nend\nend\n<\/code><\/pre>\n
This Vagrantfile will download the \u201cbento\/ubuntu-16.04\u201d image from the Vagrant repositories, which is a pre-configured Ubuntu 16.04 minimal VM. Additionally, it will create two 256 MB virtual disk files and attach them to the VM.<\/span><\/p>\n
After saving the file, start up the VM from command line in the same folder:<\/span><\/p>\n
 <\/p>\n
vagrant up<\/code><\/pre>\n
 <\/p>\n
This will completely setup and start the VM. After its completion, you can SSH into the new VM:<\/span><\/p>\n
vagrant ssh alice<\/code><\/span><\/pre>\n
 <\/p>\n
(You may omit stating the machine name, if your Vagrantfile contains only one VM)<\/span><\/p>\n
Now verify, that the additional drives exist:<\/span><\/p>\n
 <\/p>\n
vagrant@alice:~$ lsblk\nNAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT\n...\nsdb                      8:16   0  256M  0 disk\nsdc                      8:32   0  256M  0 disk<\/code><\/pre>\n
 <\/p>\n
It should list two additional drives sized 256M each. Now we\u2019ve got our playground ready, let\u2019s start setting up dm-era!<\/p>\n
Device Mapper setup<\/h2>\n
In contrast to Rackcorp\u2019s tutorial [2], we will be using only device mapper in this guide, no LVM. Keep in mind, that you can<\/em> use the dm-era mapping on LVM volumes or simply any block device just fine as well. LVM is simply using device mapper in the background anyway. All following instructions and examples are based on the sample VM setup as described above.<\/p>\n
The resulting setup we will try to achieve will look as follows:<\/p>\n
 <\/p>\n
 <\/p>\n
\"Cloud<\/p>\n
The two physical drives (sdb and sdc) each fulfill different purposes: sdb will only be used for holding the era metadata (information about changed blocks), whereas sdc will be the data device (origin), which we want to track the changed blocks of. Holding both the metadata and the origin on the same physical drive<\/a>[4]<\/sup> is not supported [4].<\/p>\n
The era device \u2013 simply called \u201cera\u201d \u2013 will be layered ontop of the origin drive (sdc), similar to a linear mapping. Further, we will logically partition sdb by applying a linear mapping called \u201cera-meta\u201d of a fixed size to it, required for the metadata. Since device mapper can\u2019t read the metadata directly from it, a second linear mapping to the metadata is required for metadata snapshots and read operations. We will create this as \u201cera-access\u201d in same size as the metadata mapping ontop of the \u201cera-meta\u201d device.<\/p>\n
Before beginning to set this up, we have to determine the size required by the metadata. And this is a tricky topic.<\/p>\n
Determining Metadata size<\/h2>\n
(You can skip this chapter<\/a>[5]<\/sup> if you are not interested in how I determined the estimated formula for metadata size requirement)<\/p>\n
Unfortunately, neither the official docs nor the dm tools themselves tell you anything about the size that will be required by the metadata device for correct function of the era device.
\nThe blog entry by Rackcorp [2] simply states that dividing the origin device\u2019s size by 1000 is sufficient.
\nHowever, that is a very rough estimate. Let\u2019s say you have a 1TB large drive you want to track blocks of using dm-era. With this formula you\u2019d estimate to reserve 1GB on another drive solely for the metadata. But actually my internal tests showed a far less space requirement than this. By several orders of magnitudes.<\/p>\n
So, I wasn\u2019t satisfied with this estimate pulled out of thin air, without any indication of what this assumption is actually based on. To get a little closer to reality you are basically left with two choices: For one you could dig into the kernel\u2019s source code related to dm-era and try to put up a formula based on the actual code \u2013 on the other hand you could simply try to estimate a formula based on a series of measurements done on differently sized era devices.
\nSince the first option requires a kernel specialist or at least someone familiar with the workings of device mapper and a sufficient amount of time on their hands, I was only left with the second option.<\/p>\n
Estimating metadata size using empirical trials<\/h3>\n
I did the tests within an Ubuntu 16.04 VM and two virtual hard drives, which will be referred to as sdb and sdc. The sdb drive is a small 256M sized drive that acted as a containment for the metadata and another up to 16TB sized sdc drive that acted as a origin for the era device.
\nNow I set up a dm-era setup which uses a fixed amount of sdc as the origin and tried to find the minimum required metadata size on sdb. For each sdc size I slowly increased the size of the linear mapping ontop of sdb by 4k steps, trying to execute the following steps each time:<\/p>\n