Hi Amir, Amir Goldstein <amir73il@xxxxxxxxx> writes: > On Mon, Aug 24, 2020 at 11:15 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> >> On Sat, Aug 22, 2020 at 11:27 AM Giuseppe Scrivano <gscrivan@xxxxxxxxxx> wrote: >> > >> > Vivek Goyal <vgoyal@xxxxxxxxxx> writes: >> > >> > > Container folks are complaining that dnf/yum issues too many sync while >> > > installing packages and this slows down the image build. Build >> > > requirement is such that they don't care if a node goes down while >> > > build was still going on. In that case, they will simply throw away >> > > unfinished layer and start new build. So they don't care about syncing >> > > intermediate state to the disk and hence don't want to pay the price >> > > associated with sync. >> > > >> >> [...] >> >> > Ping. >> > >> > Is there anything holding this patch? >> >> Not sure what happened with protection against mounting a volatile >> overlay twice, I don't see that in the patch. > > Do you mean protection only for new kernels or old kernels as well? > > The latter can be achieved by using $workdir/volatile/ as upperdir > instead of $upperdir. > Or maybe even use $workdir/work/incompat/volatile/upper, so if older > kernel tries to re-use that $workdir, it will fail to mount rw with error: > > overlayfs: cleanup of 'incompat/volatile' failed (-39) > > If we agree to that, then upperdir= should not be provided at all when > specifying "volatile". in this case, what does a program need to do to remount the overlay more than once? Is it enough to just delete a file? Thanks, Giuseppe
