[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [atomic-devel] Fedora 26 change: using overlayfs as default

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]