Re: Bug in overlay FS

[steve landiss <steve.landiss@yahoo.com>]

[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]

A company we are evaluating says they  have a fix for this and they advised me that they will send you the fix shortly.
Regards,Steve 


     On Thursday, May 21, 2015 8:38 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
   

 [Al Viro and linux-unionfs added to Cc]

On Tue, May 19, 2015 at 11:30 PM, steve landiss <steve.landiss@yahoo.com> wrote:
>
> On Tuesday, May 19, 2015 2:12 AM, Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> >
> > On Mon, May 18, 2015 at 10:35 PM, steve landiss <steve.landiss@yahoo.com>
> > wrote:
> >
> >> A data consistency bug is demonstrated by the following program:
> >>
> >> - Pick a file from the lower layer that has never been written
> >> - Open it twice once in O_RDONLY (fd1) and once in O_RDWR (fd2)
> >> - Write to fd2, read from fd1 -> data inconsistency!
> >> I understand why it happens, is there a fix planned for this?
> >
> >
>>  Not presently.
> >
> > This is a feature of both overlayfs and union-mounts.  Aufs, a full
> > union-filesystem doesn't suffer from this probelm.
> >
> > Is this causing a real-world problem, or is this purely theoretical?

> yum fails right off the bat.  Because it opens a file in read only, then
> another process or thread writes to the file.
>
> Our build process in Docker does not work because of this, and I know of
> many others that have this issue
>
> overlayfs fails to run container with a strange file checksum error · Issue
> #10180 · docker/docker

Okay, this is not easy to fix, but I wouldn't say impossible.

I think it connects with the idea of revoking file descriptors.
Except here we don't want to revoke, but replace on copy-up.

But it might be easier to just to do the union-filesystem thing.

Thanks,
Miklos

  

[-- Attachment #2: Type: text/html, Size: 3844 bytes --]