Re: [PATCH v2 08/20] ovl: lookup index entry for non-dir

From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	"linux-unionfs@vger.kernel.org" <linux-unionfs@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH v2 08/20] ovl: lookup index entry for non-dir
Date: Fri, 9 Jun 2017 15:29:58 +0200	[thread overview]
Message-ID: <CAJfpegv19YTec1BRA_z7Zi7qH+bL1s+oRGFhgSLpZGyN8qMNuA@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjBognnCN+=RmwAR88cE4TnTtCADeXSTsJW2htxqohvQA@mail.gmail.com>

On Fri, Jun 9, 2017 at 3:24 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Fri, Jun 9, 2017 at 4:14 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>> On Fri, Jun 9, 2017 at 1:49 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:
>>> On Fri, Jun 9, 2017 at 11:38 AM, Amir Goldstein <amir73il@gmail.com> wrote:
>>
>>> The challenge is in accounting the number of link-ups atomically with
>>> the link-up itself.  No ideas off-hand.
>>
>> Following would work I think:
>>
>> - copy up to indexdir (it now has st_nlink == 1)
>> - set overlay.nlinkup to "1-2"
>>   + the first number indicates the target number of linkups
>>   + the second indicates the target st_nlink on the file
>> - fsync the file (hopefully this writes the xattrs as well as the data)
>> - link the file from indexdir to upper
>> - set overlay.nlinkup to "1"
>>    + this indicates that the linkup was finished and number of linkups is 1.
>>
>> There are 3 cases when we find a file with overlay.nlinkup:
>>
>> - just one number: nothing to do
>> - two numbers and second number == st_nlink: replace with just the linkup value
>> - two numbers and second number != st_nlink: replace with decremented
>> linkup value
>>
>> So the atomicity is guaranteed by st_nlink becoming in sync with the
>> target value.
>>
>> Would need to ensure that ovl_link() is not performed in parallel with
>> the linkup procedure.
>>
>
> Yep, I started to write you the same thing :)
> I though of using a separate xattr for the transnational values,
> and delete it after link up, but I guess single xattr is cleaner ??
>
> I guess the new ovl_inode mutex could be used for blocking ovl_link().
>
> Just to be clear:
> - we are going to allocate ovl_inode from our own slab cache
> - move from using the i_private inode fields to ovl_inode fields:
>   {realinode, originode, nlinkup, lock}
> - use ovl_inode mutex instead of wait queue and for hardlink up
>
> Correct?

Sounds good.

Thanks,
Miklos