On Fri, Jun 9, 2017 at 11:38 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 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 like that.
> I would just need to implement inode_inuse_lock().
Just put the mutex in the new struct ovl_inode?
>
>>>
>>> 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.
Yes.
The challenge is in accounting the number of link-ups atomically with
the link-up itself. No ideas off-hand.
> <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?
Not yet.
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
