Re: Storage and snapshots as historical yearly

["Austin S. Hemmelgarn" <ahferroin7@gmail.com>]

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.