Sent from my iPhone
On 31/03/2011, at 17:10, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx>
wrote:
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.
Sure, I can do that.
Thanks
Amir
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
