Re: Optional switching off cow in overlayfs

[Jan Olszak <j.olszak@samsung.com>]

On 06/23/2015 11:27 AM, David Howells wrote:
> Jan Olszak <j.olszak@samsung.com> wrote:
>
>>>>>     But what should happen on rename or unlink?
>>>> Both would operate on the original inode.
>>> And that would make this hugely complex.
>> Are you sure?
> Unlink would be the same as now - you just whiteout over the lower layer.
>
> Rename, though, would be complex - unless you go for the trivial option and
> just error out.
>
> The problem is that the only connection between the upper layer and lower
> layer is coincidence governed by filename.  If you move the upper layer
> object, the lower layer object is no longer coincident and is effectively
> lost.  You cannot move the lower layer object because the lower layer may be
> shared between multiple overlays.
>
> At the moment, rename deals
>
> You could, I suppose, store a "fall through" inode in the upper layer that has
> the NFS fh of the lower layer object attached in some fashion (eg. xattr), but
> it's messy.
>
> Hard linking would be even more complex - you'd have to hard link the "fall
> through" inodes on the upper layer.
>
> David
"Fall through" inodes seem a messy solution, agreed.

Why not just say: "rename causes copy" and leave everything as it is now.
Renaming a file shared by many mounts seems to be a corner case and I 
guess overlayfs handles this well right now.

Thanks,
Jan