linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Giuseppe Scrivano <gscrivan@redhat.com>
To: Sargun Dhillon <sargun@sargun.me>
Cc: Aleksa Sarai <asarai@suse.de>,
	Linux Containers <containers@lists.linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	overlayfs <linux-unionfs@vger.kernel.org>
Subject: Re: Overlayfs @Plumbers
Date: Sun, 30 Aug 2020 13:29:51 +0200	[thread overview]
Message-ID: <87imd09xsg.fsf@redhat.com> (raw)
In-Reply-To: <CAMp4zn83CwpfuFq7+JSkYGZmFC03pUrt_30Wzn42AxqAaSDSpg@mail.gmail.com> (Sargun Dhillon's message of "Sat, 29 Aug 2020 08:40:36 -0700")

Hi Sargun,

Sargun Dhillon <sargun@sargun.me> writes:

Q> 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?

we are having the same issue when building images.  Would the following
patch be helpful?

https://www.spinics.net/lists/linux-unionfs/msg08267.html

Regards,
Giuseppe


  reply	other threads:[~2020-08-30 11:30 UTC|newest]

Thread overview: 7+ 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:58   ` Aleksa Sarai
2020-08-29 15:40     ` Sargun Dhillon
2020-08-30 11:29       ` Giuseppe Scrivano [this message]
2020-08-30 11:37       ` 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=87imd09xsg.fsf@redhat.com \
    --to=gscrivan@redhat.com \
    --cc=asarai@suse.de \
    --cc=containers@lists.linux-foundation.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=sargun@sargun.me \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).