On 12/13/2016 01:02 PM, Colin Walters wrote:
> On Tue, Dec 13, 2016, at 12:45 PM, Clayton Coleman wrote:
>> Are the POSIX issues in applications running on overlay mostly
>> resolved now? I.e. if we flipped the default would be reasonably
>> able to support a diverse range of Linux workloads without the risk
>> that previously existed?
>
> overlayfs will never be fully POSIX compatible, but I think that's OK,
> because remember - you shouldn't use overlayfs for persistent data,
> or really anything that's not code/config files (and we want to get
> to where that's overlayfs-type semantics for builds, and read-only
> for deployment). Data should be in Kube persistent volumes etc.
>
> I think the thing to focus on is tools that are run during builds - the
> yum-in-overlayfs bug is a good example, because the RPM database
> *is* a database which is the type of workload that's going to
> be sensitive to the overlayfs semantics. How many of those
> are there? Probably not many, I suspect most of the compat
> issues with userspace have been shaken out by now.
>
> (But long term we may end up in a situation where people
> who want to run e.g. rhel5's yum in a container need to
> somehow fall back to devmapper)
>
I have heard that the issue with yum/rpm is being worked on in the kernel.
For those that to not know the issue is for programs that open a file twice
once for readonly and then later for read/write. In the first open the
file is
on the lower file system. When you open the second time for read/write,
Overlay does a COPY/UP which creates a separate file. The program thinks
that it has the same file opened twice, but it actually has two
different files
open.
