On Fri, Nov 10, 2017 at 4:21 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote:
> On Tue, Oct 24, 2017 at 01:02:59PM +0300, Amir Goldstein wrote:
>> Kconfig description on OVERLAY_FS_INDEX states that "the inodes index
>> feature is read-only backward compatible" and that mounting an overlay
>> with index enabled, disabled and then enabled again "will have
>> unexpected results."
>>
>> Commit d1712d8fef03 ("ovl: fix EIO from lookup of non-indexed upper")
>> makes the results of this enable/disable/enable maneuver just as
>> expected and the results of a plain enable of index feature on existing
>> overlay - some hardlinks may have already been broken and new hardlinks
>> will not be broken on copy up.
>>
>> Now that there is a dedicated config option to opt-in in for backward
>> incompatible index feature, remove the backward compatibility clause from
>> Kconfig description of OVERLAY_FS_INDEX.
>
> What if user does OVERLAY_FS_INDEX_INCOMPAT=n, then this text is still
> relevant?
>
In theory Yes.
Because at the moment, after fixing the EIO behavior,
I am not aware of anything making OVERLAY_FS_INDEX non backward compat.
You upgrade to index=on
copy up doesn't break hardlinks
downgrade to index=off
copy up breaks hardlinks
upgrade to index=on
copy up joins indexed hardlinks
...
and so on.
Unless there is something else I didn't think of.
The idea with introducing the explicit option OVERLAY_FS_INDEX_INCOMPAT
is that any new index feature (e.g. full index for NFS export) can require
user to commit to not going backwards (i.e. mount -o index=off will fail).
Perhaps we need to work out the details of the allowed transistions
better then I defined them.
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
