# Docker storage drivers
**URL:** https://meta.discourse.org/t/docker-storage-drivers/88897
**Category:** Self-hosting
**Created:** [June 1, 2018, 5:48am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897 "2018-06-01T05:48:53Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Danpiel](https://meta.discourse.org/u/Danpiel)
#### Post date: [June 1, 2018, 5:48am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/1 "2018-06-01T05:48:53Z")
Hello, switched storage driver to devicemapper (direct-lvm) and Discourse refuses to rebuild, why devicemapper option is filtered since it is one of the proper production setups. Do not confuse with **loop-lvm** , where loop devices are created in filesystem, they have terrible performance. The **direct-lvm** uses hard drive directly, without interaction with host filesystem.
More info here [Device Mapper storage driver (deprecated) | Docker Docs](https://docs.docker.com/storage/storagedriver/device-mapper-driver/#configure-direct-lvm-mode-for-production)
In general, most suitable options for storage should be **overlay2** , **devicemapper** (direct-lvm mode) and **btrfs**. The first one is default one, good performance, reliable. The devicemapper and btrfs gives ability to snapshot the data, easier to manage backups. Also devicemapper is good for write heavy operations, btrfs has superior performance but not all systems support it.
Simple fix for now to allow devicemapper, can I open PR ?
```plaintext
diff --git a/launcher b/launcher
index 9d44cda..ec2964a 100755
--- a/launcher
+++ b/launcher
@@ -136,7 +136,7 @@ check_prereqs() {
fi
# 2. running an approved storage driver?
- if ! $docker_path info 2> /dev/null | egrep -q '^Storage Driver: (aufs|btrfs|zfs|overlay|overlay2)$'; then
+ if ! $docker_path info 2> /dev/null | egrep -q '^Storage Driver: (aufs|btrfs|zfs|overlay|overlay2|devicemapper)$'; then
echo "Your Docker installation is not using a supported storage driver. If we were to proceed you may have a broken install."
echo "aufs is the recommended storage driver, although zfs/btrfs/overlay and overlay2 may work as well."
echo "Other storage drivers are known to be problematic."
```
---
### Author:  [@codinghorror](https://meta.discourse.org/u/codinghorror)
#### Post date: [June 1, 2018, 9:56am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/2 "2018-06-01T09:56:25Z")
No, because we don’t support devicemapper based on the large number of problems we’ve had with it in the past. If you’d like to skip that step for your install, you are welcome to do so of course.
---
### Author:  [@Danpiel](https://meta.discourse.org/u/Danpiel)
#### Post date: [June 1, 2018, 11:45am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/3 "2018-06-01T11:45:12Z")
Even issues with **direct-lvm**? Can mention those issues ?
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [June 1, 2018, 1:35pm UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/4 "2018-06-01T13:35:53Z")
We had lots of issues with the standard out of the box devicemapper, so we block it by default.
If you did your homework and is sure that your storage driver is up to the task, just add `--skip-prereqs` to the launcher command line.
---
### Author:  [@Danpiel](https://meta.discourse.org/u/Danpiel)
#### Post date: [June 3, 2018, 8:03am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/5 "2018-06-03T08:03:38Z")
Thanks a lot for override flag, no pain for updating and backporting changes.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [June 3, 2018, 8:10am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/6 "2018-06-03T08:10:04Z")
Please report back here in say 2-3 months after say 5-10 rebuilds, I am very curious to see if this holds for you. Also be sure to post your exact version of Docker and Kernel with explanation on how you set up DM just-so.
---
### Author:  [@Danpiel](https://meta.discourse.org/u/Danpiel)
#### Post date: [June 3, 2018, 8:19am UTC](https://meta.discourse.org/t/docker-storage-drivers/88897/7 "2018-06-03T08:19:25Z")
Sure, will keep you updated.
One moment I already found, by using software RAID 1 (mdadm) on plain sata disks with lvm gives performance degradation, uses a lot of cpu time for syncing. On 8 core system load average was 2-4, after the switch to btrfs on same RAID1, reduced the load to 1-2.
But I keep testing the direct-lvm, might find the bottleneck