From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: Union mounts and fchown/fchmod/utimensat Date: Tue, 30 Mar 2010 00:48:43 +0100 Message-ID: <20100329234843.GG9876@shareable.org> References: <20100326224533.GB29874@shell> <23818.1269704603@jrobl> <20100329183925.GA24328@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "J. R. Okajima" , linux-fsdevel@vger.kernel.org, Alexander Viro , Erez Zadok , Christoph Hellwig To: Valerie Aurora Return-path: Received: from mail2.shareable.org ([80.68.89.115]:49114 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754589Ab0C2Xsu (ORCPT ); Mon, 29 Mar 2010 19:48:50 -0400 Content-Disposition: inline In-Reply-To: <20100329183925.GA24328@shell> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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? Rename-over updates will be fine with that, and there'll be no unexpected long delays to do copyup of a huge file. -- Jamie