On Tue, Jan 30, 2018 at 10:15 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: > On Tue, Jan 30, 2018 at 10:05:08PM +0200, Amir Goldstein wrote: >> On Tue, Jan 30, 2018 at 10:03 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> > On Tue, Jan 30, 2018 at 9:33 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> >> On Tue, Jan 23, 2018 at 03:47:29PM +0200, Amir Goldstein wrote: >> >>> On Tue, Jan 23, 2018 at 3:45 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> >>> > On Mon, Jan 22, 2018 at 09:46:33PM +0200, Amir Goldstein wrote: >> >>> >> On Mon, Jan 22, 2018 at 9:34 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >>> >> > On Mon, Jan 22, 2018 at 8:39 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> >>> >> >> There is a need to support metacopy dentry in midlayer. That means there >> >>> >> >> could be a chain of metacopy dentries. >> >>> >> >> >> >>> >> >> For example, upper could be metacopy, midlayer lower could be metacopy and >> >>> >> >> lowest layer could be actual data inode. This means when we copy up actual >> >>> >> >> data, we should be able to reach to lowest data inode and copy up data from >> >>> >> >> there. And that means we should keep track of all the dentries in origin >> >>> >> >> chain which lead to data inode. >> >>> >> >> >> >>> >> >> Current ovl_check_origin() logic only looks for one origin dentry. This patch >> >>> >> >> enhances ovl_check_origin() to continue to follow origin chain and return >> >>> >> >> all the origin entries found. This is done only if caller of the function >> >>> >> >> set "follow_chain" argument. >> >>> >> >> >> >>> >> > >> >>> >> > We don't really need to keep the entire chain do we? >> >>> >> > We can follow chain but keep only the one inode that is not a metacopy inode. >> >>> >> > All the rest are useless, no? >> >>> >> > Then we don't create a new type of object - non-dir with numlower > 1. >> >>> >> > >> >>> >> >> >>> >> Seems like if you don't keep the entire chain, then no need for >> >>> >> patches 14 and 15. >> >>> > >> >>> > I will need to have atleast 2 lower dentries. One will be top most >> >>> > metadata copy and other lower most data dentry. IOW, both the ends of >> >>> > the chain need to be there. >> >>> > >> >>> >> Also with upper metacopy, you can fix upper origin xattr after >> >>> >> following to the data >> >>> >> origin and forget about middle layer metacopies forever. >> >>> > >> >>> > If upper metacopy is alreday there, then I agree that lower top most >> >>> > becomes inner node of chain and we can get rid of it. >> >>> > >> >>> >> >> >>> >> Am I missing something? >> >>> > >> >>> > I think you are missing the case when there is no upper and lower has >> >>> > a metacopy chain. In that case we need to retain two dentries. One for >> >>> > data copy up and one for metadata copy up. >> >>> > >> >>> >> >>> OK. so you can get rid of all the middle metacopies while following >> >>> the origin chain. no reason to keep those. >> >> >> >> Hi Amir, >> >> >> >> What about the case when we have upper and one middle metacopy. As of top >> >> most lower is the ORIGIN for upper. Should we retain that top most lower >> >> ORIGIN as well as lower most data. Or just retain lower most data and >> >> use that as ORIGIN. >> >> >> > >> > Not sure I follow. >> > IIUC, the longest possible chain is lowerstack size 2: >> > upper -> metadata ORIGIN -> data ORIGIN >> > >> >> If you are wondering if we could drop the metadata ORIGIN, >> I think we need it at least for constant and persistent st_ino. > > Right, I was wondering can be drop metadata ORIGIN and just live with > data ORIGIN. > > My initial impression is that constant and persistent st_ino can be > achieved using just data ORIGIN alone as well. But I might be missing > some finer detail. > That makes sense some to me (st_ino from data ORIGIN), but it may complicate the code in several cases that assume that st_ino and file handle and index key all come from lowerstack[0]. So I guess I lean towards always keeping metadata ORIGIN around and using its inode for st_ino and index file handle. Amir. -- 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
