On 06/23/2015 11:27 AM, David Howells wrote:
Jan Olszak <j.ols...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
