On Wed, Jul 26, 2017 at 12:19 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> Wait, copy-up creates index, no? > > That's what I thought at first, but then realized we only *need* to > index renamed and unlinked upper objects for NFS export. > My concern w.r.t. indexing on copy up was that performance of index > create and lookup can degrade for large index dir, so better index > only what we need in order to be able to decode. Guessing that there won't be many merge dirs in most situations, so this won't be an issue. > But if copy up creates index then behavior of (d) can be well defined. > B.t.w my current NFS export WIP does index on copy up. Lets keep it that way for the first version. >>> Bottom line is that splitting follow origin to a new mount flag for >>> snapshot is fine by me. Do you intend to preserve the behavior change >>> of NOT following unverified lower dir? Without this change ESTALE >>> error could become persistent. >> >> I don't get it. > > Right. That involves some more lower renames. Imagine 2 merged dirs A > and B both decoded by origin. Then the 2 lower dirs swapped. Now > decode of A yields an inconsistent index so return ESTALE. But lookup > of A will follow to unverified lower B and encode of that dentry will > be same as encode of B before the swap, so we are bound to always get > ESTALE after encode/decode. I suppose there are other ways out of this > loop hole besides not following unverified lower. I just don't see > them right now. Aren't we allowed to update the stale index? Thanks, Miklos -- 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
