* 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.