Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752434AbZIQU4P (ORCPT ); Thu, 17 Sep 2009 16:56:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751471AbZIQU4K (ORCPT ); Thu, 17 Sep 2009 16:56:10 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:51798 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751286AbZIQU4J (ORCPT ); Thu, 17 Sep 2009 16:56:09 -0400 Date: Thu, 17 Sep 2009 13:55:44 -0700 (PDT) From: Linus Torvalds X-X-Sender: torvalds@localhost.localdomain To: Roland Dreier cc: Joel Becker , 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: Message-ID: References: <20090914221434.GA4507@mail.oracle.com> <20090915000417.GC4507@mail.oracle.com> <20090915005417.GD4507@mail.oracle.com> <20090915040601.GE4507@mail.oracle.com> <20090915214530.GA11060@mail.oracle.com> <20090916044047.GA30453@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: 1832 Lines: 41 On Thu, 17 Sep 2009, Roland Dreier wrote: > > > I guess one bit of semantics to figure out is what happens if copyfile() > > > does the async case but then copyfile_ctrl() returns an error halfway > > > through... is the state of the dest file just undefined? > > > I think that's the one that most filesystems would prefer. Maybe the file > > is there, it's just that it's only half copied because the filesystem > > filled up. > > Makes sense... and even having the state of having the file half-copied > is not really well-defined since a filesystem may want to optimize > things by copying out of order etc. Yeah. The thing to remember is that where you'd use a non-atomic 'copyfile()' system call is as a replacement for just doing the same thing by hand in user space, so any users of this system call would basically have to handle the "oops, it failed with ENOSPC in the middle" _anyway_. So there is no downside to saying "ok, it failed in the middle, you clean up the result", because the user needs to support that anyway. The ones that use copyfile for filesystem-specific snapshots and use the ATOMIC bit to say so obviously don't have this issue. But they aren't looking for a "faster 'cp'" thing - they're looking for very specific semantics, and for the ATOMIC case we can provide those kinds of nice atomic "everything or nothing" semantics. So the fact that some random server-side copy over CIFS/NFS may need cleanup by the user after failing at half-point is not actually a downside. It doesn't affect Joel's kind of fancy use. 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/