Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755158AbZIRAaP (ORCPT ); Thu, 17 Sep 2009 20:30:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754872AbZIRAaN (ORCPT ); Thu, 17 Sep 2009 20:30:13 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:46978 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754871AbZIRAaM (ORCPT ); Thu, 17 Sep 2009 20:30:12 -0400 Date: Thu, 17 Sep 2009 17:29:39 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Joel Becker cc: Roland Dreier , Mark Fasheh , Andrew Morton , Linux Kernel Mailing List , ocfs2-devel@oss.oracle.com Subject: Re: [GIT PULL] ocfs2 changes for 2.6.32 In-Reply-To: <20090917203453.GA15620@mail.oracle.com> Message-ID: References: <20090915005417.GD4507@mail.oracle.com> <20090915040601.GE4507@mail.oracle.com> <20090915214530.GA11060@mail.oracle.com> <20090916044047.GA30453@mail.oracle.com> <20090917203453.GA15620@mail.oracle.com> User-Agent: Alpine 2.01 (LFD 1184 2008-12-16) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2134 Lines: 48 On Thu, 17 Sep 2009, Joel Becker wrote: > > I have to say, adding 'undefined behavior' things isn't fun in a > call that is already potentially confusing. We have a bunch of flags > and behaviors we're covering. I don't think it's "undefined". It's just not complete. >From a user standpoint, there is no difference between such a system call and doing the thing as a library routine (which has to be the fallback anyway for something like 'cp'). > Note that "cleaning up after an error" and "atomic" are not the > same. Atomicity implies that not only do you see all or none, but that > the contents are a point-in-time of the source file. A non-atomic > implementation may be affected by writes that happen during the copy > (like any read-write-loop copy would be). Sure. There are middle grounds that may not need the cleanup. I was more looking at the two extreme ends. > > Of course, if the filesystem can do the copy entirely atomically (ie by > > just incrementing a refcount), then it can give atomicity guarantees, but > > then you'd never see the async case either. > > Even the atomic copy might take a little time (say, to bump up > and write out the metadata structures). Do you want to define that as > not being async? I was figuring COPYFILE_ATOMIC and COPYFILE_WAIT to be > separate flags. I don't think that's wrong, and yeah, you could decide that you actually want to be able to support the "ten outstanding 'copy' commands from user space" model too. So yeah, separate COPYFILE_ATOMIC (only succeed if you can do it as an atomic op in the filesystem) and COPYFILE_WAIT (only return when fully done) bits sounds conceptually fine to me. Whether it's worth it for a filesystem that effectively only needs a couple of writes (that can be buffered too), I dunno. But it's certainly not something I'd object to on an interface level. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/