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

Amir Goldstein
2017-06-09T13:24:41Z

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?

Amir.