From mboxrd@z Thu Jan  1 00:00:00 1970
From: Tao Ma <tao.ma@oracle.com>
Subject: Re: [PATCH 1/3] fs: Document the reflink(2) system call.
Date: Mon, 04 May 2009 09:44:32 +0800
Message-ID: <49FE4880.3010208@oracle.com>
References: <1241331303-23753-1-git-send-email-joel.becker@oracle.com> <1241331303-23753-2-git-send-email-joel.becker@oracle.com> <20090503234518.GB17044@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Joel Becker <joel.becker@oracle.com>,
	linux-fsdevel@vger.kernel.org, jmorris@namei.org,
	ocfs2-devel@oss.oracle.com, viro@zeniv.linux.org.uk
To: Theodore Tso <tytso@mit.edu>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from acsinet11.oracle.com ([141.146.126.233]:32885 "EHLO
	acsinet11.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751243AbZEDBpM (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Sun, 3 May 2009 21:45:12 -0400
In-Reply-To: <20090503234518.GB17044@mit.edu>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Hi Ted,

Theodore Tso wrote:
> On Sat, May 02, 2009 at 11:15:01PM -0700, Joel Becker wrote:
>> int reflink(const char *oldpath, const char *newpath);
>>
>> The reflink(2) system call creates reference-counted links.  It creates
>> a new file that shares the data extents of the source file in a
>> copy-on-write fashion.  Its calling semantics are identical to link(2).
>> Once complete, programs see the new file as a completely separate entry.
> 
> How should quota handle reflinks?  Since there are separate inodes,
> the two files could be owned by different user ID's.  Since the data
> blocks exist only once, I can imagine a number of different ways of
> handling it:
> 
> 1) When the reflink is created, the owner of the new reflink is not
> charged the number of blocks of the file against his/her quota.  If
> the original inode is deleted, the original owner continues to have
> the cost of the file charged against his/her quota until the last
> reflink disappears.
> 
> 2) When the reflink is created, the owner of the new reflink is NOT
> charged the number of blocks of the file against his/her quota.  If
> the original inode is deleted, the owner of the reflink is charged the
> number of blocks against his/her quota.  If that drives the owner over
> quota, the quota subsystem will enforce the soft and hard quota limits
> as per normal.  If there are more than one reflink against the file,
> the system will randomly choose one user and charge the blocks against
> his/her quota.
> 
> 3) When the reflink is created, the owner of the new reflink is
> charged the number of blocks of the file against his/her quota.  The
> original owner of the inode continus to also have the blocks of the
> file charged against his/her quota, so in effect the blocks are
> "double counted".
> 
> 4) When the reflink is created, the owner of the new reflink is NOT
> charged the number of blocks of the file against his/her quota.  The
> original owner of the inode continues to also have the blocks of the
> file charged against his/her quota; if the file is deleted the blocks
> associated with the file will not be charged against any users' quota.
> 
> All of these have various problems; and maybe the answer is that
> reflinks aren't really compatible with quotas, so pick something least
> bad (say #3), and we can just move on.
yeah, agree. So I will pick #3 in my ocfs2 reflink implementation.

Thanks.

Regards,
Tao