On Sat, Jun 10, 2017 at 1:56 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> On Fri, Jun 9, 2017 at 4:14 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>> On Fri, Jun 9, 2017 at 1:49 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>>> On Fri, Jun 9, 2017 at 11:38 AM, Amir Goldstein <amir73il@xxxxxxxxx> 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.
>>
>
> Or like this:
>
> struct ovl_nlink_adjust {
> int nlink_diff;
> bool from_lower;
> }
>
> Init overlay inode:
> overlay_nlink := (from_lower ? lower_nlink : upper_nlink) + nlink_diff
>
> Copy/link up:
> - take ovl_inode lock
> - set overlay.nlink { (overlay_nlink - lower_link), true }
> - link index (won't change diff from lower inode nlink on fail/success)
>
> Unlink/link/rename:
> - take ovl_inode lock
> - set overlay.nlink { (overlay_nlink - upper_nlink), false }
> - unlink/link/rename (won't change diff from upper nlink on fail/success)
>
> I don't think fsync matters to this game.
> I'd be surprised if the nlink changing operations (link/unlink/rename) can be
> reordered with the setxattr operations on a power fail safe fs.
>
Miklos,
FYI, I've implemented the scheme above and it seems to work fine:
https://github.com/amir73il/linux/commits/ovl-nlink
Also wrote an xfstest to exercise persistent nlink:
https://github.com/amir73il/xfstests/commits/overlayfs-devel
I'll post persistent nlink along with ovl-hardlink v4 when I am done with
index evict/cleanup.
Amir.
