On Fri, Nov 10, 2017 at 3:57 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Tue, Oct 24, 2017 at 01:02:58PM +0300, Amir Goldstein wrote: >> Introduce a new config option OVERLAY_FS_INDEX_INCOMPAT. >> >> If this config option is enabled then inodes index is declared >> an incompatible feature and kernel will refuse to mount an overlay >> with inodes index off when a non-empty index directory exists. >> >> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> >> --- >> fs/overlayfs/Kconfig | 8 ++++++++ >> fs/overlayfs/dir.c | 30 ++++++++++++++++++++++++++++++ >> fs/overlayfs/overlayfs.h | 3 ++- >> fs/overlayfs/super.c | 24 +++++++++++++++++++++++- >> 4 files changed, 63 insertions(+), 2 deletions(-) >> >> diff --git a/fs/overlayfs/Kconfig b/fs/overlayfs/Kconfig >> index cbfc196e5dc5..e5e6dec7d177 100644 >> --- a/fs/overlayfs/Kconfig >> +++ b/fs/overlayfs/Kconfig >> @@ -43,3 +43,11 @@ config OVERLAY_FS_INDEX >> outcomes. However, mounting the same overlay with an old kernel >> read-write and then mounting it again with a new kernel, will have >> unexpected results. >> + >> +config OVERLAY_FS_INDEX_INCOMPAT >> + bool "Overlayfs: support incompatible index feature" >> + depends on OVERLAY_FS_INDEX >> + help >> + If this config option is enabled then inodes index is declared an >> + incompatible feature and kernel will refuse to mount an overlay with >> + inodes index off when a non-empty index directory exists. > > Hi Amir, > > I don't know much about the issues you have faced. So I have few very > basic questions. > > So the problem you are trying to fix is that if somebody mounted overlay > with index=on and later they try to mount it with index=off. > > What problems happen if we allow that? If its a problem, why not always > disallow that instead of making it an option. IOW, is there a use case > where we will still let user mount later with index=off. > So I have no current issue with going back from index=on, but I would like to start adding incompatible features (like index=all), but in order to add the concept of incompatible feature, first user will need to opt-in in compile time to "overlayfs v2 format" which supports the feature checks. opting-in to format v2 means that user knows he cannot (*) go backwards to kernel that doesn't support v2 format and mount v2 format overlayfs. Actually, the user can go backwards, but he will need to manually remove workdir and indexdir in order to "degrade" overlayfs to v1 before mount. I guess config option could have been OVERLAY_FS_INCOMAT_V2 and it doesn't even need to make index=on an incompat feature as this patch does, but it was easier for me to implement it this way. OTOH, if users cannot enable index=on on existing systems because of the exclusive lock thing, it is better if users go directly to OVERLAY_FS_INDEX_INCOMPAT on a flag day when thier system has adapted to all the new behaviors of index=on and there is not really any good reason to mount with index=off. If for example, user migrates layers and mount fails file handle verifications then user should either fix file handles with fsck.overlayfs or kill the index dir (not migrate it in the first place) and then user can mount with index=off. Hope this brings more clarity to the purpose of this series. Comments and thought are welcome. Thanks, 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
