All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: Bug in overlay FS
       [not found] ` <1084458602.2805420.1432071057532.JavaMail.yahoo@mail.yahoo.com>
@ 2015-05-21 15:38   ` Miklos Szeredi
  2015-05-22  0:51     ` steve landiss
  0 siblings, 1 reply; 2+ messages in thread
From: Miklos Szeredi @ 2015-05-21 15:38 UTC (permalink / raw)
  To: steve landiss; +Cc: linux-unionfs, Al Viro

[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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Bug in overlay FS
  2015-05-21 15:38   ` Bug in overlay FS Miklos Szeredi
@ 2015-05-22  0:51     ` steve landiss
  0 siblings, 0 replies; 2+ messages in thread
From: steve landiss @ 2015-05-22  0:51 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: linux-unionfs, Al Viro

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-05-22  0:51 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAJfpegt+O78vh_FcLSVxqY6gnzR7t0GW-D0=RuvyvqikR=RTXQ@mail.gmail.com>
     [not found] ` <1084458602.2805420.1432071057532.JavaMail.yahoo@mail.yahoo.com>
2015-05-21 15:38   ` Bug in overlay FS Miklos Szeredi
2015-05-22  0:51     ` steve landiss

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.