On 2017-09-13 07:51, Pete wrote:
On 09/12/2017 01:16 PM, Austin S. Hemmelgarn wrote:
Diverting away from the original topic, what issues with overlayfs and
btrfs?
As mentioned, I thought whiteout support was missing, but if you're
using it without issue, I might be wrong.
Whiteout works fine. Upper and lower layers and working directory are
all on btrfs subvolumes. Snapshotting seems fine.
Hmm, just double checked myself. Apparently I was operating based on
old information.
I'm using btrfs to create 'base' operating system containers (btrfs) and
then using overlayfs for a few 'upper' containers for specific
applications, so the upper parts of the overlays contain only the config
and data files and I can apply OS updates only on the lower ones.
I do note that changes in the 'base' os can take time to propagate to
the upper containers and I'm probably not being sensible in not stopping
the upper containers when updating the lower ones. This is also does
not seem to be what overlaysfs is intended for. However, for my light
usage it generally works OK and is useful to me.
Actually, this is pretty well in-line with one of the intended use cases
(it was mostly designed for efficient multiple instantiation of Docker
or LXC containers). The other big use case is 'live' systems that only
retain state while powered on, like most install images.
OK, I only spotted the latter use case when reading up, apart from one
website which seemed to mention using it for containers.
Yeah, containers are the other big one. It's not unusual for someone to
need to spin up a dozen or more instances of essentially the same
container (think large build systems), and without an overlay mount, you
end up multiplying the space for the base image times the number of
containers.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
