On Wed, May 10, 2017 at 12:21 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, May 10, 2017 at 10:58 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >> Is it too soon to nudge you about the pull request? ;-) > > I'll have a look. > > My plan is to send a pull request to Linus for the const ino stuff, > and then leave the rest to 4.13. > Sure, no rush about verify_lower, I just meant to nudge about the pull request for const ino. > This is the list I have in my head for what's missing: > > - lookup origin dir for snapshots > - const ino for non-samefs > - correct d_ino for copied up entries > - NFS export support > - hardlink unbreaking > - sharing pages for reflink (*) > - ro/rw correctness for samefs with temp reflink (**) > - sharing pages in the general case (*) > Just updated TODO with the a similar list yesterday ;) https://github.com/amir73il/overlayfs/wiki/Overlayfs-TODO > (*) very preliminary design > (**) need to check overhead: I have a feeling that it's a heavyweight > solution for a tiny problem > I am hoping to reduce the code complexity (of rocopyup) after we have the workdir/inodes/ index, because taking care of rocopyup/rwcopyup races can be similar to taking care of link/unlink/link races... we'll see how it goes. The read pages performance overhead should be reasonable with sharing pages. The inode create/delete overhead is something we will need to measure, but from my experience with xfs, I suspect that the cost is going to be fair enough that some people would like to pay it to get the "tiny" problem solved. Also, the "tiny" problem is also going to be manifested with hardlinks copy up, where it may need to be fixed anyway. see this commit message for the details: https://github.com/amir73il/linux/commit/62a16f3389187d3c3efa22293bf65cdb7bd619c5 > The non-starred ones don't seem too hard and should aim for 4.13. > Indeed. I am going to start with hardlinks and const d_ino soon. The case of non-dir is easier to handle first because: 1. workdir/inodes/#lower_ino is a hard link to upper, so fewer follow by file handles involved 2. const d_ino for directory is not very interesting - 'find' always uses stat() to get inode number of directory, so 'find -ino N' is not affected by non-const dir d_ino. Cheers, Amir.
