On 19 March 2010 22:47, Michal Suchanek <hramrach@xxxxxxxxxx> wrote: > Hello > > On 19 March 2010 19:03, Valerie Aurora <vaurora@xxxxxxxxxx> wrote: > >> >> Where union mounts is right now is in need of more review from VFS >> experts (and thanks to those who have already reviewed it). I'm > > I don't count myself among VFS experts so I'm sorry if I am restating > or missing something obvious. > >> rewriting the in-file copyup code right now, which is dependent on a >> lot of ongoing VFS work by Al Viro, Nick Piggin, Dmitriy Monakhov, and >> others. Here's my description of the problem I'm currently working, >> which is where I could use review the most: >> >> http://groups.google.com/group/linux.kernel/msg/217ca5aedbd7bfd0 >> > > On Mar 16, 7:20 pm, Valerie Aurora <vaur...@xxxxxxxxxx> wrote: >> This patch shows the basic data flow necessary to implement efficient >> union mount file copyup (without the actual file copyup code). I need >> input from other VFS people on design, especially since namei.c is >> getting some much needed reorganization. Some background: >> >> In union mounts, a file on the lower, read-only file system layer is >> copied up to the top layer when an application attempts to write to >> it. This is in-kernel file copyup. Some constraints make this >> difficult: >> >> 1. Don't copyup if the operation would fail (e.g., open(O_WRONLY) on a >> file with mode 444). It's inefficient and a possible security hole to >> copy up a file if no write (or maybe even read) can occur anyway. > > The open fails in that case anyway so I see no reason to copy > anything. Why would you copy before you open? > Actually the lookup is probably done as namei so the file should be copied up anyway because the result is an inode number and to guarantee that next namei would return the same number it's far easiest to just create the top inode and return that. The alternative is, of course, to create numerous lookup tables in memory and for every operation consult the tables to determine in what state the object in question currently is. Thanks Michal -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
