Hi Sargun, Sargun Dhillon <sargun@xxxxxxxxx> writes: Q> On Fri, Aug 28, 2020 at 8:59 AM Aleksa Sarai <asarai@xxxxxxx> wrote: >> >> On 2020-08-28, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: >> > Amir Goldstein <amir73il@xxxxxxxxx> 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
