[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] Direct LVM by default
- From: Dusty Mabe <dustymabe gmail com>
- To: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] Direct LVM by default
- Date: Thu, 25 Sep 2014 12:37:48 -0400
On Thu, Sep 25, 2014 at 12:12:36PM -0400, Colin Walters wrote:
> On Thu, Sep 25, 2014, at 11:45 AM, Karanbir Singh wrote:
>
> > why have a different filesystem for docker, why not leave it in the
> > tree, and expand the entire root filesystem ?
>
> This is a complex topic. I recommend reading:
> https://github.com/docker/docker/blob/master/daemon/graphdriver/devmapper/README.md
> if you haven't first.
>
> The docker default (without AUFS or btrfs or overlayfs) is loopback
> inside an existing filesystem, and this has a large performance cost;
> having a filesystem inside a filesystem is like TCP inside TCP, or virt
> in virt. For example, with loopback every block gets cached twice.
>
> By pointing docker at a directly allocated LVM block device, it's both
> faster and has more powerful management opportunities.
>
> For example, say you want to expand your Docker container storage on
> Atomic in the new model. It looks something like this:
>
> # lvm pvcreate /dev/sdb
> # lvm vgextend atomicos /dev/sdb
> # lvm lvextend -l '+100%FREE' atomicos/docker--data
> # systemctl restart docker
Just a personal preference here but just so the atomicos VG is completely
contained on the new storage it would be ideal to migrate the volume group
entirely (using pvmove) and then remove the old PV from the VG.
If you don't do this then what Thomas desired (being able to nuke hosts and not
lose container information/data) is pointless.
My $.02
Dusty
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]