From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Fri, 22 May 2015 00:51:03 +0000 (UTC) From: steve landiss Reply-To: steve landiss Message-ID: <423094758.67304.1432255863385.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: Bug in overlay FS MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_67303_2052761729.1432255863381" To: Miklos Szeredi Cc: "linux-unionfs@vger.kernel.org" , Al Viro List-ID: ------=_Part_67303_2052761729.1432255863381 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A company we are evaluating says they =C2=A0have a fix for this and they ad= vised me that they will send you the fix shortly. Regards,Steve=20 On Thursday, May 21, 2015 8:38 AM, Miklos Szeredi = wrote: =20 [Al Viro and linux-unionfs added to Cc] On Tue, May 19, 2015 at 11:30 PM, steve landiss w= rote: > > On Tuesday, May 19, 2015 2:12 AM, Miklos Szeredi wrot= e: > > > > > > On Mon, May 18, 2015 at 10:35 PM, steve landiss > > 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? > > > > >>=C2=A0 Not presently. > > > > This is a feature of both overlayfs and union-mounts.=C2=A0 Aufs, a ful= l > > 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.=C2=A0 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 =C2= =B7 Issue > #10180 =C2=B7 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 ------=_Part_67303_2052761729.1432255863381 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A company we are evaluating says they  hav= e a fix for this and they advised me that they will send you the fix shortl= y.

Regards,
Steve



On Thursday, May 21, 2015 8:38 AM, Miklos Szeredi <miklos@szered= i.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 1= 0:35 PM, steve landiss <steve.landiss@yahoo.co= m>
> > 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 onc= e in O_RDWR (fd2)
> >> - Write to fd2, read from= fd1 -> data inconsistency!
> >> I understand= why it happens, is there a fix planned for this?
> &g= t;
> >
>>  Not present= ly.
> >
> > This is a featu= re of both overlayfs and union-mounts.  Aufs, a full
> > union-filesystem doesn't suffer from this probelm.
> >
> > Is this causing a real-world pro= blem, or is this purely theoretical?

&= gt; 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 ot= hers that have this issue
>
> ove= rlayfs fails to run container with a strange file checksum error =C2=B7 Iss= ue
> #10180 =C2=B7 docker/docker
Okay, this is not easy to fix, but I wouldn't say impossibl= e.

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

But i= t might be easier to just to do the union-filesystem thing.


Thanks= ,
Miklos


= ------=_Part_67303_2052761729.1432255863381--