[EMAIL PROTECTED] wrote on 08/06/2006 11:38:56 PM: > > > I am thinking that one answer to this issue is to add a new void > > > *i_stacked_inode to the inode struct. If an existing valid lower inode > > > is found on interpose, then just associate the stacked inode pointed > > > to by i_stacked_inode with the stacked dentry. > > > > What will happen after the cached dentry and inode are freed, by > > shrink_dcache() or something? Is your i_stacked_inode freed too? Is it > > still available? > > I will try writing-down in other words. > > - assuming that the copyup feature exists > - create the hardlink, "ln /ro_branch/fileA /ro_branch/fileB" > - mount as /stacked_fs = /rw_branch + /ro_branch > - you will see those two files > - append to the fileA, "echo abc >> /stacked_fs/fileA" > - you will see both of the files are updated correctly > - other operation which accesses the huge number of inodes, for example > "find / -ls". The cached inodes of those two files will be gone. > - then, i am afraid the stacked_fs cannot follow the i_stacked_inode > chain. read from /stacked_fs/fileB. you will see the old contents of > fileA, won't you? That seems right. I don't think any current Unionfs solution fixes that, but this issue is orthogonal to the i_stacked_inode solution, which means that Unionfs at least knows two lower-level files are the same when it instantiates Unionfs inodes.
Charles _______________________________________________ unionfs mailing list unionfs@mail.fsl.cs.sunysb.edu http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
