From: Amir Goldstein Subject: Re: [Lsf-pc] [LSF/FS TOPIC] Ext4 snapshots status update Date: Thu, 31 Mar 2011 20:58:07 -0700 Message-ID: <96658895-D787-4E77-8CC5-51F72FEF8500@gmail.com> References: <20110204002043.GA15658@noexit> <20110330003429.GA32669@noexit> <1301485711-sup-3080@think> <1301616609.26686.25.camel@lade.trondhjem.org> Mime-Version: 1.0 (iPhone Mail 7D11) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: Chris Mason , lsf-pc , Joel Becker , linux-fsdevel , Ext4 Developers List , Josef Bacik To: Trond Myklebust Return-path: In-Reply-To: <1301616609.26686.25.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-ext4.vger.kernel.org Sent from my iPhone On 31/03/2011, at 17:10, Trond Myklebust wrote: > On Wed, 2011-03-30 at 14:08 +0200, Amir Goldstein wrote: >> On Wed, Mar 30, 2011 at 1:50 PM, Chris Mason >> wrote: >>> Excerpts from Amir Goldstein's message of 2011-03-30 00:16:45 -0400: >>>> On Wed, Mar 30, 2011 at 2:34 AM, Joel Becker >>>> wrote: >>>>> On Wed, Mar 23, 2011 at 10:19:38PM +0200, Amir Goldstein wrote: >>>>>> On Fri, Feb 4, 2011 at 2:20 AM, Joel Becker >>>>>> wrote: >>>>>>> On Fri, Feb 04, 2011 at 12:33:39AM +0200, Amir Goldstein wrote: >>>>>>> I've already got a design for a front-end snapshot >>>>>>> program that >>>>>>> implements a policy on top this generic behavior. This design >>>>>>> would >>>>>>> cover both first-class and hidden style snapshots, because it >>>>>>> assume >>>>>>> snapshots are in a distinct namespace. I haven't gotten >>>>>>> around to >>>>>>> implementing it yet, but btrfs and other snapshottable >>>>>>> filesystems were >>>>>>> part of the design goal. >>>>>> >>>>>> Any chance of getting a copy of that design of yours, to get a >>>>>> head start >>>>>> for LSF? >>>>> >>>>> Yeah, I owe it to you. It wasn't a written-down thing, it >>>>> was a >>>>> hammered-out-in-our-heads thing among some ocfs2 developers. >>>>> I'm going >>>>> to braindump here to get us going. First, I'll speak to your >>>>> points. >>>>> >>>>>> Here are some other generic snapshot related topics we may want >>>>>> to discuss: >>>>>> >>>>>> 1. Collaborating the use of inode flags COW_FL, NOCOW_FL, >>>>>> suggested by Chris. >>>>> >>>>> I'm unsure where these fit, perhaps because I missed the >>>>> discussion between Chris and you. ocfs2 has the inode flag >>>>> OCFS2_REFCOUNTED_FL to signify a refcount tree is attached to >>>>> the inode. >>>>> This is ocfs2's structure for maintaining extent reference >>>>> counts. Is >>>>> your COW_FL the same? Or is it a permission flag? NOCOW_FL >>>>> sounds >>>>> like: "Set this flag on the inode and it will prevent CoW." >>>> >>>> I don't have a use for COW_FL, since my snapshots are volume >>>> level snapshots. >>>> I intend to use NOCOW_FL to mark an inode as an "island" of NOCOW >>>> blocks in the volume. >>>> Maybe Chris or Josef can elaborate of the flags intended use in >>>> btrfs. >>> >>> NOWCOW_FL in btrfs means to directly overwrite blocks (and not do >>> crcs) >>> unless the block has another reference. If there is another >>> reference, >>> we COW once to honor the snapshot and then continue in NOCOW mode. >>> >>> I'm kind of worried about your NOCOW island idea, maybe we can >>> talk more >>> about that next week. It seems like it will lead to a lot of admin >>> surprises. >>> >> >> Yes, that's something to talk about. >> My desire for NOCOW comes from lack of sub volume granularity >> in ext4 snapshots. >> >> My NOCOW design states that NOCOW flag cannot be toggled on a >> regular file. >> like a snapshot file, a NOCOW file must be born and die NOCOW, to >> avoid >> admin surprises. NOCOW directories (which ARE COWed) are were NOCOW >> files are born. >> >> Using this scheme, an admin can exclude->include->exclude directory >> sub trees >> from snapshots. > > OK. I'd like to schedule a general talk about the state of snapshots > and > future improvements. I'm assuming you would like to lead the debate. > Sure, I can do that. Thanks Amir > Cheers > Trond > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com >