On Wed, Oct 18, 2017 at 4:03 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Wed, Oct 18, 2017 at 07:31:51AM +0300, Amir Goldstein wrote: >> On Wed, Oct 18, 2017 at 12:05 AM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> > By default metadata only copy up is disabled. Provide a mount option so >> > that users can choose one way or other. >> > >> > Also provide a kernel config and module option to enable/disable >> > metacopy feature. >> > >> > Like index feature, when overlay is mounted, on root upper directory we >> > set ORIGIN which points to lower. And at later mount time it is verified >> > again. This hopes to get the configuration right. But this does only so >> > much as we don't verify all the lowers. So it is possible that a lower is >> > missing and later data copy up fails. >> >> Like index feature, please error mount if ovl_inuse_trylock fails. >> As you know, this error is only conditional because of backward >> compatibility, so any new opt-in feature should enforce it. > > Hi Amir, > > I am not so sure about it. Avoiding leaking any mount point is really > really hard. And I don't think current container runtime have been > modified to make it fool proof. > > IMHO, if we really want to enforce something like this, then we need > to have some sort of capability to find existing superblock and reuse it. > (Something like what happens with block devices). > That sounds like a good idea. Any chance you can make it happen? Keep in mind that would be a change of behavior, so users will have to opt-in for it as well. > I am afraid that if I start enforcing this, then this feature will not > be used at all because software has not been hardended enough to avoid > mount point leaks completely. > I find that approach a bit dodgy. If not for enjoying new overlayfs feature, why would container runtime developers ever bother to fix mount leaks. Anyway, that is up to Miklos to decide. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
