lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1301485711-sup-3080@think>
Date:	Wed, 30 Mar 2011 07:50:15 -0400
From:	Chris Mason <chris.mason@...cle.com>
To:	Amir Goldstein <amir73il@...il.com>
Cc:	Joel Becker <jlbec@...lplan.org>,
	lsf-pc <lsf-pc@...ts.linuxfoundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Theodore Tso <tytso@....edu>, Josef Bacik <josef@...hat.com>
Subject: Re: [LSF/FS TOPIC] Ext4 snapshots status update

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@...lplan.org> 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@...lplan.org> 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.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ