On Fri, Jun 9, 2017 at 11:43 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> On Thu, Jun 8, 2017 at 6:09 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
>> You mean iterate all existing the overlay inode dentry cache aliases?
>
> Yes.
>
> And locking is needed. The INUSE flag could provide that, but I'd
> prefer something local to the overlay instance (i.e. in ovl_fs). The
> reason is that lower layers could be shared and then separate
> instances would be interfering with each other, which is not nice.
> First version could just do a single mutex in ovl_fs. Could refine
> that to an array of locks hashed by origin inode, or something.
>
Then how about inuse_lock the overlay inode?
It is already unique among all lower/upper aliases.
In fact, oe->copying and ovl_{start,end}_copy_up could probably
be moved from the overlay dentry to the overlay inode.
It should work the same for the old use cases and provide the needed
(granular) locking for hardlinks copy-aliases-up.
I would just need to implement inode_inuse_lock().
Am I missing something?
>>
>> While on the subject, maybe you also have an idea about how to
>> account for whiteouts *before* the first copy up:
>
> Ah, another special case. We could un-special it by doing the copy-up
> to index anyway before commencing with the delete (only for i_nlink >
> 1, obviously). Bit of a hack, but would make things simpler.
>
This certainly works for my use case of clone up, so I don't mind wiring up
this workaround. We would still need to keep persistent count of copy ups
(e.g. in trusted.overlay.nlink of upper), because the condition to whiteout the
index on mount/evict is (origin->i_nlink == trusted.overlay.nlink &&
index->i_nlink == 1), but I was planning to do that anyway.
<soliciting> copy-up-on-delete is also classic use case for metadata-copy-up.
And then we can proceed to metadata-index-copy-up on open for read to
solve the consistent ro/rw fd.
Did you get a chance to look at the page mapping sharing?
Hey, I already set i_data.privae_data to the origin inode.
All you need to do is steel the pages ;-) </soliciting>
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
