From: "Austin S. Hemmelgarn" <ahferroin7@gmail.com>
To: Pete <pete@petezilla.co.uk>, linux-btrfs@vger.kernel.org
Subject: Re: Storage and snapshots as historical yearly
Date: Tue, 12 Sep 2017 08:16:03 -0400 [thread overview]
Message-ID: <3e3eae9d-f7d0-fafb-6faf-6eecdf724c8b@gmail.com> (raw)
In-Reply-To: <34d8d690-d999-0081-4a80-65a6de439639@petezilla.co.uk>
On 2017-09-11 17:36, Pete wrote:
> On 09/11/2017 07:49 PM, Austin S. Hemmelgarn wrote:
>
>> Unfortunately, I don't know of any overlay mount implementation that
>> works correctly and reliably with BTRFS. I know for a fact that
>> OverlayFS (the upstream in-kernel implementation) does not work, and I
>> believe that AUFS3 and UnionFS (the third-party options that are used by
>> most LiveCD's) don't work either. UnionFS-FUSE (a userspace
>> implementation completely unrelated to UnionFS) might work, but I've
>> never tested it and it will likely have performance issues because it's
>> implemented in userspace. As far as I know, whiteout support is the
>> primary missing piece here, but I may be mistaken.
>>
>
> 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.
>
> 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.
next prev parent reply other threads:[~2017-09-12 12:16 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-11 18:17 Storage and snapshots as historical yearly Senén Vidal Blanco
2017-09-11 18:49 ` Austin S. Hemmelgarn
2017-09-11 21:36 ` Pete
2017-09-12 12:16 ` Austin S. Hemmelgarn [this message]
2017-09-13 11:51 ` Pete
2017-09-13 12:26 ` Austin S. Hemmelgarn
2017-09-19 19:09 ` Senén Vidal Blanco
2017-09-12 3:34 ` Andrei Borzenkov
2017-09-19 11:49 ` Senén Vidal Blanco
2017-09-19 18:33 ` Andrei Borzenkov
2017-09-19 19:19 ` Austin S. Hemmelgarn
2017-09-21 10:07 ` Senén Vidal Blanco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e3eae9d-f7d0-fafb-6faf-6eecdf724c8b@gmail.com \
--to=ahferroin7@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=pete@petezilla.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.