On Tue, Mar 30, 2010 at 12:48:43AM +0100, Jamie Lokier wrote: > Valerie Aurora wrote: > > I'm working on the assumption that this is okay. Basically, an > > in-kernel copyup has the same effect on an application with an > > O_RDONLY fd as a userland copy-up to a temporary file followed by a > > rename() to the original name. Editors, among other applications, use > > this sequence all the time. If it breaks under union mount copyup, it > > will also break if you edit the file with vi. > > Ouch. That's fine for rename-over style updates, but if an > application depends on in-place updates, or if it depends on file > locking to serialise something (using O_RDONLY for read locks and > O_RDWR for write locks), it will get confused. > > Now, that may be acceptable compromise non-POSIX behaviour. > > But if it only works with rename-over style updates.... Why have > in-kernel copyup at all? Why not simply forbid writes to lower files? Hm, I'm not sure we're on the same page. In-kernel copyup will work transparently in most cases. An application that opens multiple fds with O_RDWR or O_WRONLY will see completely coherent changes. It's only when an app opens a file O_RDONLY, and then depends on seeing writes or metadata changes from some other agency (another app, or an fd opened with write permission) that union mounts will break things. The question is how common that is. Does that make sense or I did I miss your point? -VAL -- 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
