On Fri, Apr 7, 2017 at 12:47 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > Come to think about it, NFS export of regular file don't need to > follow renames at all: > - The handle for a regular file is always the handle for the real > lower or upper inode > - To decode a handle, create an O_TMPFILE style overlay dentry, which > is not linked > to any path in overlay, but has the _upperdentry/lowerstack setup I don't think nfs will allow such a scheme. NFS3 server is stateless, which means there's no open/close in the protocol. Hence we can't copy-up on open(O_WR*) and return a different file handle for writing. If client looks up a file currently on lower and we return file handle based on lower file, then we must be able to decode that handle after the file has been copied up and even after rename. And this must work reliably even if the overlay dentry is no longer in the dcache. So there's no option, other than to have a reverse mapping somewhere. One more idea: do it out-of-band (e.g. under workdir) but do it as a plain directory tree shadowing the lower trees that contains the forward redirect information. It spares us the implementation of the database, since the filesystem does it for us. Yes, it can get out of sync with the overlay, but so can any mapping in-band or out-of-band. 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
