On Mon, Jun 19, 2017 at 10:45 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 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)
What I don't like about this is how it ends up in different states
depending on the last operation. How about moving "set overlay.nlink
{ (overlay_nlink - upper_nlink), false }" into the link-up region as
well?
>> 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.
Why not? I know data changes can be reordered around rename without
an fsync, for example.
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
