From: Sargun Dhillon <sargun@sargun.me>
To: Aleksa Sarai <asarai@suse.de>
Cc: Linux Containers <containers@lists.linux-foundation.org>,
"Eric W. Biederman" <ebiederm@xmission.com>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: Overlayfs @Plumbers
Date: Sat, 29 Aug 2020 08:40:36 -0700 [thread overview]
Message-ID: <CAMp4zn83CwpfuFq7+JSkYGZmFC03pUrt_30Wzn42AxqAaSDSpg@mail.gmail.com> (raw)
In-Reply-To: <20200828155849.k46uk3x63aio3g3o@yavin.dot.cyphar.com>
On Fri, Aug 28, 2020 at 8:59 AM Aleksa Sarai <asarai@suse.de> wrote:
>
> On 2020-08-28, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Amir Goldstein <amir73il@gmail.com> writes:
> >
> > > Hi Guys,
> > >
> > > It's been nice to virtually meet with you yesterday.
> > > Some of you wanted to follow up on overlayfs related issues.
> > >
> > > If you want to discuss, try to find me in one of the
> > > https://meet.2020.linuxplumbersconf.org/hackrooms
> > > today between 16:00-17:00 UTC
> > > (No need to enter the room to see who's inside)
> > >
> > > If those times do not work for you, contact me and we can try
> > > to schedule another time.
> >
> > Did this conversation wind up happening? Do we need to reschedule?
>
> This conversation already happened in a Hackroom on Tuesday. I'm not
> sure if the Hackrooms will have their recordings published, so maybe
> Amir can post any of the takeaways we had?
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> <https://www.cyphar.com/>
I unfortunately missed this conversation. I wanted to bring up OverlayFS, and
ephemeral upper dirs. We use overlayfs with Docker containers, and we waste
a lot of time on writing things back to disk.
We're not so peeved about the fact that OVL does any sync operations, as that's
what our users have been used to. The big problem is on unmount, ovelfs decides
syncing the upperdirs is a good idea. IIRC, this regression was
introduced somewhere
in the 4.X series.
We've been carrying a patch to short-circuit this behaviour for a while now:
https://github.com/Netflix-Skunkworks/linux/commit/edb195d9b73cc22d095078010a14a690f41ee253
I know that this behaviour (and any behaviour that short-circuits
O_SYNC / FUA is
technically "wrong", but in this case, can we make an exception? I originally
thought about using device mapper to remove the FUA bit from all BIOs, but it
turns out that my underlying storage *always* persists data to disk,
so every write
takes...a long time.
Amir, what's your take?
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers
WARNING: multiple messages have this Message-ID (diff)
From: Sargun Dhillon <sargun@sargun.me>
To: Aleksa Sarai <asarai@suse.de>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Amir Goldstein <amir73il@gmail.com>,
Linux Containers <containers@lists.linux-foundation.org>,
overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: Overlayfs @Plumbers
Date: Sat, 29 Aug 2020 08:40:36 -0700 [thread overview]
Message-ID: <CAMp4zn83CwpfuFq7+JSkYGZmFC03pUrt_30Wzn42AxqAaSDSpg@mail.gmail.com> (raw)
In-Reply-To: <20200828155849.k46uk3x63aio3g3o@yavin.dot.cyphar.com>
On Fri, Aug 28, 2020 at 8:59 AM Aleksa Sarai <asarai@suse.de> wrote:
>
> On 2020-08-28, Eric W. Biederman <ebiederm@xmission.com> wrote:
> > Amir Goldstein <amir73il@gmail.com> writes:
> >
> > > Hi Guys,
> > >
> > > It's been nice to virtually meet with you yesterday.
> > > Some of you wanted to follow up on overlayfs related issues.
> > >
> > > If you want to discuss, try to find me in one of the
> > > https://meet.2020.linuxplumbersconf.org/hackrooms
> > > today between 16:00-17:00 UTC
> > > (No need to enter the room to see who's inside)
> > >
> > > If those times do not work for you, contact me and we can try
> > > to schedule another time.
> >
> > Did this conversation wind up happening? Do we need to reschedule?
>
> This conversation already happened in a Hackroom on Tuesday. I'm not
> sure if the Hackrooms will have their recordings published, so maybe
> Amir can post any of the takeaways we had?
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> <https://www.cyphar.com/>
I unfortunately missed this conversation. I wanted to bring up OverlayFS, and
ephemeral upper dirs. We use overlayfs with Docker containers, and we waste
a lot of time on writing things back to disk.
We're not so peeved about the fact that OVL does any sync operations, as that's
what our users have been used to. The big problem is on unmount, ovelfs decides
syncing the upperdirs is a good idea. IIRC, this regression was
introduced somewhere
in the 4.X series.
We've been carrying a patch to short-circuit this behaviour for a while now:
https://github.com/Netflix-Skunkworks/linux/commit/edb195d9b73cc22d095078010a14a690f41ee253
I know that this behaviour (and any behaviour that short-circuits
O_SYNC / FUA is
technically "wrong", but in this case, can we make an exception? I originally
thought about using device mapper to remove the FUA bit from all BIOs, but it
turns out that my underlying storage *always* persists data to disk,
so every write
takes...a long time.
Amir, what's your take?
next prev parent reply other threads:[~2020-08-29 15:48 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-25 6:07 Overlayfs @Plumbers Amir Goldstein
2020-08-28 15:33 ` Eric W. Biederman
2020-08-28 15:33 ` Eric W. Biederman
2020-08-28 15:58 ` Aleksa Sarai
2020-08-28 15:58 ` Aleksa Sarai
2020-08-29 15:40 ` Sargun Dhillon [this message]
2020-08-29 15:40 ` Sargun Dhillon
2020-08-30 11:29 ` Giuseppe Scrivano
2020-08-30 11:29 ` Giuseppe Scrivano
2020-08-30 11:37 ` Amir Goldstein
2020-08-30 11:37 ` Amir Goldstein
2020-08-30 11:44 ` Amir Goldstein
2020-08-30 11:44 ` Amir Goldstein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMp4zn83CwpfuFq7+JSkYGZmFC03pUrt_30Wzn42AxqAaSDSpg@mail.gmail.com \
--to=sargun@sargun.me \
--cc=asarai@suse.de \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-unionfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.