On Wed, Mar 30, 2011 at 1:50 PM, Chris Mason [off-list ref] wrote:

Excerpts from Amir Goldstein's message of 2011-03-30 00:16:45 -0400:

quoted

On Wed, Mar 30, 2011 at 2:34 AM, Joel Becker [off-list ref] wrote:

quoted

On Wed, Mar 23, 2011 at 10:19:38PM +0200, Amir Goldstein wrote:

quoted

On Fri, Feb 4, 2011 at 2:20 AM, Joel Becker [off-list ref] wrote:

quoted

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.

quoted

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.

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html