On Wed, 2011-03-30 at 14:08 +0200, Amir Goldstein wrote: > On Wed, Mar 30, 2011 at 1:50 PM, Chris Mason <chris.mason@xxxxxxxxxx> 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 <jlbec@xxxxxxxxxxxx> 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 <jlbec@xxxxxxxxxxxx> 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. Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
