From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [Lsf-pc] [LSF/MM][ATTEND]filesystem -- reflink Date: Wed, 15 Jan 2014 10:03:12 +0100 Message-ID: <20140115090312.GA6732@quack.suse.cz> References: <52D635C4.20201@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org To: mingming cao Return-path: Received: from cantor2.suse.de ([195.135.220.15]:41834 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750856AbaAOJDP (ORCPT ); Wed, 15 Jan 2014 04:03:15 -0500 Content-Disposition: inline In-Reply-To: <52D635C4.20201@oracle.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hello, On Tue 14-01-14 23:16:20, mingming cao wrote: > I'd like to attend Linux storage and filesystem summit. I am > interested in discussion of general lockless direct io and more > interested in discussion of reflink support for filesystem. Btrfs > and OCFS2 has this support, My goal is explore what's best to way > this support for ext4. If there is any crossover work between > filesystem and vfs people, or filesystem and dm layer I am more than > happy to discuss about it too. There was a project for implementing COW for ext4 but it was a really major surgery and in the end didn't get to an upstreamable state. Reflink is somewhat simpler than general COW because it's only about fs data. In particular implementing reflink with a file granularity (i.e., a type of hardlink which is automatically converted to a copy when first opened for writing) is relatively simple to do but I'm not sure how useful it is. Doing reflink properly with block granularity is harder with block refcounting etc. Do you have any particular usecase in mind? Honza -- Jan Kara SUSE Labs, CR