Cute! I was wondering why Gitlab uses MR and whether Gitlab has a better term just the other day, because I figured it was such an illogical phrase. As it happens, I am in the middle of installing Gitlab again on a newly reconfigured server and this popped up!
Then I thought "Hey, why not use the docker image?" (reeling from deep pain from the last time I tried to upgrade an LXC-based Gitlab instance across major versions), then I wondered if I needed aufs, then I wound up reading presentations about storage drivers (zfs FTW, but shame on docker for wanting an entire zpool to itself!), then decided overlay was better (and in-kernel), then I wanted to switch to a PaX kernel, now I've got a day of recompilation and installations ahead of me. But I will be glad to know MRs lie at the end ;) +1 docker bug: https://github.com/docker/docker/issues/20303
I was not planning to use LVM because it's documented[0] as slow and resource hungry... full copy each time, massive memory use, etc.
CONFIG_OVERLAY_FS is mainline kernel code (unlike aufs) and not marked as experimental so if docker's implementation is buggy it is more likely to be docker's fault. It is documented by docker as being generally fast.[1]
Regardless, I don't see performance as a great concern for my workloads... I'm more interested in the workflow enhancements.
Then I thought "Hey, why not use the docker image?" (reeling from deep pain from the last time I tried to upgrade an LXC-based Gitlab instance across major versions), then I wondered if I needed aufs, then I wound up reading presentations about storage drivers (zfs FTW, but shame on docker for wanting an entire zpool to itself!), then decided overlay was better (and in-kernel), then I wanted to switch to a PaX kernel, now I've got a day of recompilation and installations ahead of me. But I will be glad to know MRs lie at the end ;) +1 docker bug: https://github.com/docker/docker/issues/20303