On Wed, Jan 24, 2018 at 11:05 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Mon, Jan 22, 2018 at 7:39 PM, Vivek Goyal <vgoyal@xxxxxxxxxx> wrote: >> Hi, >> >> Please find attached V10 of the metadata only copy up patches. I think >> I have taken care of review comments and I will start writing automated >> test cases now. >> >> One thing which concerns me about these patches is the fact that during >> file open d_real() will return lower inode which actually contains file >> data and that inode will be installed in f->f_inode. So while f->f_inode >> is perfectly fine for data operations, it is not fine for metadata >> operations. Because metadata has been copied up and is represented by >> a different inode. >> >> I am concerned that this is a subtle behavior change and especially >> security modules might be surprised by it. I will spend now more time >> looking at what security modules are doing with f->f_inode. Thoughts? > > This is exactly the same situation where there is an r/o open and > copy-up later. Except this makes it more widespread. So I don't > think any new issues are introduced (doesn't mean there aren't any old > ones). > > The only risk I see with this feature is exactly the fact that the > ro/rw inconsistency can happen more often, which might break more > cases. I'd really like to work on getting rid of this issue. > Hopefully next cycle... > About that. I suppose you mean taking the route of intercepting overlayfs file operations, so the only remaining concern would be mmap? FYI, I am still maintaining my "copy on read" patches [1] and use them for snapshots. The last patch is a late addition that is aimed at integrating with metacopy for "copy on read" for non-clone/non-same fs case. Rummer has it [2] that Matthew Wilcox is going to tackle sharing page cache between cloned inodes. Mathew, I wanted to bring the overlayfs "metacopy" use case to your attention, so you can take it into account when implementing page cache sharing. This was more or less the solution proposed by Al to inconsistent data of a r/o open file: - Create a "metacopy" inode in upper layer when opening a file for read - Share page cache of lower layer inode with upper layer "metacopy" inode - When upper file is opened for write, data is copied to upper inode and page cache sharing is broken. - After breaking page cache sharing, the upper inode becomes the backing inode, but unshared pages content is guarantied to be uptodate and non dirty So "metacopy" is an all-or-nothing private case of file cloning. If undelying fs supports clones, then page cache sharing is not broken on open for write, but it is converted from "metacopy" situation, to the common cloned file situation - the backing inode is the upper inode, bit its shares all the blocks with lower inode. Please keep linux-unionfs posted when you have any progress. I'd be happy to test any WIP you might have. Thanks, Amir. [1] https://github.com/amir73il/linux/commits/ovl-rocopyup [2] https://marc.info/?l=linux-xfs&m=151705246227384&w=2 -- 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
