Getting a writable filesystems on Node
The diagram illustrates how we plan to bring a writable root filesystem to Node, without any limitations. No limitations, because the fs is justa regular filesystem, nothing special about it, the special handling is below, on the block layer, provided by LVM thin volumes (thanks to dm-thin):
. . . . . . . . . . . . . . . .
: : :
: +--------------+--------------+
: | layer-1 (rw) | layer-2 (rw) |
: +--------------+--------------+
: | base-1 (ro) | base-2 (ro) |
+------------+ +--------------+--------------+-----------+
| bootloader | | lvm vg |
+------------+--+-----------------------------------------+
| disk |
+---------------------------------------------------------+
Each image (called base-N
) we publish will be stored as a read-only
(thin) logical volume in the volume group (lvm vg
). For each base
base-N
a writable layer named layer-N
will be created atop of the
base. To boot into the writable layers, boot entries will be added to
the bootloader, pointing to all available (writable) layers. There is no
possibility to boot into the read-only bases.
State If modifying/customizing of a layer is interpreted as the state of a base, then migrating the custom configuration between layers (i.e. migrating the changes to from an old to a new layer), can be called persisting the state of a base.
Apparently there are many ways how the state of a base can be persisted. It has been discussed and will be discussed, yet it is not clear what the Königsweg is.
And it’s obvious that base-N
is intended to be an ancestor of
base-(N+1)
.
Block layer Hiding the sparseness in the block layer has the big advantage that it is completely transparent to file based stuff, like permissions and (especially) SELinux.
It currently has the drawback that deduplication is harder - or impossible.
::: {#footer} [ October 20th, 2014 2:14pm ]{#timestamp} [node]{.tag} [ovirt]{.tag} [imgbase]{.tag} [imgbased]{.tag} [persistence]{.tag} :::