dm-cache

Now is the time to assemble the dm-cache device for the first time and see how it works. Ensure that your original file system is unmounted before proceeding.

Find the actual size of your SSD used for caching blocks. According to this mailing list posting, the metadata size will be about 4 MB + ( 16 bytes * nr_blocks ), where nr_blocks is ths number of blocks on the device volume. For this tutorial I'm going to use 256 KB (262144 bytes) cache block size. To keep the math simple, ignore the chunk that is about to be cut out from the metadata from the entire SSD partition allocated for the caching. Determine the size:

$ sudo blockdev --getsize64 /dev/disk/by-id/scsi-SATA_OCZ-AGILITY2_f2d200034-part6
96782516224

Calculate the ssd-metadata size in bytes: 4194304 + (16 * 96782516224 / 262144) = 10101440, where 96782516224 is the total size of our ssd cache partition. The result is the size of the metadata partition in bytes, convert it to number of sectors: 10101440 / 512 = 19729.375, round up to 19730 to play it safe.
Create the ssd-metadata dm device and zero it out so it isn't misinterpreted by dm-cache (happened to me when re-creating caches):

$ sudo dmsetup create ssd-metadata --table '0 19730 linear /dev/disk/by-id/scsi-SATA_OCZ-AGILITY2_f2d200034-part6 0'
$ sudo dd if=/dev/zero of=/dev/mapper/ssd-metadata

Calculate the remaining size available for ssd-blocks: 96782516224 / 512 - 19730 = 189008622
Create the ssd-blocks dm device that will hold the actual data blocks, it will follow the metadata region:

$ sudo dmsetup create ssd-blocks --table '0 189008622 linear /dev/disk/by-id/scsi-SATA_OCZ-AGILITY2_f2d200034-part6 19730'

Determine and number of sectors of your existing file system you want to add cache support to:

$ sudo blockdev --getsz /dev/vg0/spindle
1048576000

Create the actual dm-cache device with 256 KB cache blocks (512 * 512):

$ sudo dmsetup create home-cached --table '0 1048576000 cache /dev/mapper/ssd-metadata /dev/mapper/ssd-blocks /dev/vg0/spindle 512 1 writeback default 0'

Verify that the device was created and working:

$ ls -l /dev/mapper/home-cached
lrwxrwxrwx 1 root root 7 Jun 30 22:20 /dev/mapper/home-cached -> ../dm-5
$ sudo dmsetup status /dev/mapper/home-cached
0 1048576000 cache 1105/65536 144554 179602 336023 1797 0 1 28139 28139 0 2 migration_threshold 2048 4 random_threshold 4 sequential_threshold 512

Put it to use by mounting it:

$ sudo mkdir /mnt/cache
$ sudo mount /dev/mapper/home-cached /mnt/cache

Play with it, re-run the status command from above to view cache status.
That's it. Simple as that. Let me know what you think. Note, the home-cached device will disappear on reboot, so init scripts will need to be setup to properly construct the dm-cache block device each time. See the next section for hints on how to do that on Ubuntu with upstart.

Install init Scripts to Setup SSD Cache At Boot

Ubuntu upstart script to setup the device-mapper devices every time at boot and cleanly shutdown the device-mapper devices the moment the volume is unmounted using inotify:

Install these files as root under /etc/init. Upstart will take care of the rest on next reboot.
Actually Using It

I have backed up my old files and then copied them to my ssd-cached file system. I create symlinks from my more important file systems to this test file system. Again, the goal is test it for now. Later I'll use dm-cache to cache my entire /home file system and won't need symlinks.

My $HOME/.cache directory is an excellent test candidate. Things like file browsing (thumbnails and what not) are stored on the ssd-cached file system and are much snappier then before. Google Chrome stores its caches under $HOME/.cache here too, so cached web browsing is now faster.

Another good idea is the Linux kernel source tree. Running git grep on files cached by the ssd is significantly faster.

Go wild. Let me know what other clever things I can cache before I take the risk of putting my entire /home file system on a dm-cache volume.
Disabling The Cache

If you ever want to decommission the cache, you'll need to run the cleaner policy. The cleaner policy will write all the dirty cached blocks back to the underlying device. In a nutshell it works like this:

$ sudo umount /dev/mapper/home-cached
$ sudo dmsetup table home-cached
0 1048576000 cache 252:3 252:4 252:0 512 1 writeback default 0
$ sudo dmsetup status home-cached
0 1048576000 cache 737/2466 1018 224354 0 3 0 89 89 0 0 2 migration_threshold 2048 4 random_threshold 4 sequential_threshold 512
$ sudo dmsetup suspend home-cached
$ sudo dmsetup reload home-cached --table '0 1048576000 cache 252:3 252:4 252:0 512 0 cleaner 0'
$ sudo dmsetup resume home-cached
$ sudo dmsetup wait home-cached

In theory, you should be able to fsck on the underlying device (/dev/vg0/spindle) and it should look just fine at this point. You could then disable the init script and never use the cache again. Alternatively you could reconfigure it to your heart's content.

Follow this up with dmsetup remove

(Forrás)