All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Valerie Aurora <vaurora@redhat.com>
Cc: "J. R. Okajima" <hooanon05@yahoo.co.jp>,
	linux-fsdevel@vger.kernel.org,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Erez Zadok <ezk@cs.sunysb.edu>,
	Christoph Hellwig <hch@infradead.org>
Subject: Re: Union mounts and fchown/fchmod/utimensat
Date: Tue, 30 Mar 2010 00:48:43 +0100	[thread overview]
Message-ID: <20100329234843.GG9876@shareable.org> (raw)
In-Reply-To: <20100329183925.GA24328@shell>

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

  reply	other threads:[~2010-03-29 23:48 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-26 22:45 Union mounts and fchown/fchmod/utimensat Valerie Aurora
2010-03-27 15:43 ` J. R. Okajima
2010-03-29 18:39   ` Valerie Aurora
2010-03-29 23:48     ` Jamie Lokier [this message]
2010-03-30 11:16       ` Theodore Tso
2010-03-30 20:30         ` Valerie Aurora
2010-03-30 21:31       ` Valerie Aurora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100329234843.GG9876@shareable.org \
    --to=jamie@shareable.org \
    --cc=ezk@cs.sunysb.edu \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=vaurora@redhat.com \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.