On Mon, Jun 19, 2017 at 10:45 AM, Amir Goldstein [off-list ref] wrote:

On Sat, Jun 10, 2017 at 1:56 AM, Amir Goldstein [off-list ref] wrote:

quoted

On Fri, Jun 9, 2017 at 4:14 PM, Miklos Szeredi [off-list ref] wrote:

quoted

On Fri, Jun 9, 2017 at 1:49 PM, Miklos Szeredi [off-list ref] wrote:

quoted

On Fri, Jun 9, 2017 at 11:38 AM, Amir Goldstein [off-list ref] wrote:

quoted

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?

quoted

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