Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757411AbZINWQJ (ORCPT ); Mon, 14 Sep 2009 18:16:09 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756794AbZINWQI (ORCPT ); Mon, 14 Sep 2009 18:16:08 -0400 Received: from acsinet11.oracle.com ([141.146.126.233]:42382 "EHLO acsinet11.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755118AbZINWQH (ORCPT ); Mon, 14 Sep 2009 18:16:07 -0400 Date: Mon, 14 Sep 2009 15:14:35 -0700 From: Joel Becker To: Linus Torvalds Cc: Mark Fasheh , Andrew Morton , linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com Subject: Re: [GIT PULL] ocfs2 changes for 2.6.32 Message-ID: <20090914221434.GA4507@mail.oracle.com> Mail-Followup-To: Linus Torvalds , Mark Fasheh , Andrew Morton , linux-kernel@vger.kernel.org, ocfs2-devel@oss.oracle.com References: <20090911200458.GA15416@mail.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Burt-Line: Trees are cool. X-Red-Smith: Ninety feet between bases is perhaps as close as man has ever come to perfection. User-Agent: Mutt/1.5.20 (2009-06-14) X-Source-IP: acsmt356.oracle.com [141.146.40.156] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4AAEC089.0080:SCFMA4539814,ss=1,fgs=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2472 Lines: 61 On Mon, Sep 14, 2009 at 02:32:36PM -0700, Linus Torvalds wrote: > On Fri, 11 Sep 2009, Joel Becker wrote: > > > > Linus, et al, > > Here are the ocfs2 feature changes for 2.6.32. The big ticket > > item is the reflinkat(2) system call and ocfs2's support for it. The > > ocfs2 support accounts for all but a handful of the changes. The > > remaining few patches are fixes. > > I _really_ want some kind of ack's for new filesystem system calls like > this. I'm not going to pull a new 'reflink[at]()' system call just based > on a single filesystem. I'll get specific acks. I sent it via ocfs2.git because others recommended I not send it upstream in June but instead wait until I had at least one filesystem implementing it. > Yes, there's clearly been _some_ discussion, but (a) I've not seen it > (since it's been on 'fsdevel', which is one of those single-topic mailing > lists that I'm totally uninterested in, since they tend to become clique > groups) and (b) you don't even say whether the thing has been acked by > things like the security angle etc. Fair enough. Don't worry, the security folks were involved. I'll get direct acks. > I also don't understand why it's called 'reflink'. Why not 'copyfile'? We > should not name things by implementation, we should name things by what > they _do_. And I'm not seeing what is so 'reflink' about this that it's > not a 'copyfile'. I also am not entirely clear on why you need the source > name, and not - for example - an 'fd'. > > Are we going to add 'freflink[at]()' at some point? It's a link(2) analogue. symlink(2) has the loosest coupling, and reflink(2) the highest. We're not going to add freflink[at](). It's a snap, not a copy. It can be used to implement a copy, and copyfile() in libc can be written with reflinkat(2), but it isn't just a copy. Joel -- "There is shadow under this red rock. (Come in under the shadow of this red rock) And I will show you something different from either Your shadow at morning striding behind you Or your shadow at evening rising to meet you. I will show you fear in a handful of dust." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 -- 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/