linux-ext4 - Re: [LSF/FS TOPIC] Ext4 snapshots status update

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]

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