linux-ext4 - Re: Introducing Next3 - built-in snapshots support for Ext3

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:	Sat, 8 May 2010 13:25:57 -0400
From:	tytso@....edu
To:	"Amir G." <amir73il@...rs.sourceforge.net>
Cc:	Ric Wheeler <rwheeler@...hat.com>, Andi Kleen <andi@...obates.de>,
	linux-ext4@...r.kernel.org
Subject: Re: Introducing Next3 - built-in snapshots support for Ext3

On Sat, May 08, 2010 at 06:07:40PM +0200, Amir G. wrote:
> 
> Next3 is another implementation of the extended f/s format.
> Next3 is a superset of ext3 plus snapshots.

As long as Next3 uses fields which have already assigned to ext4, this
is a claim that you can not make correctly.  Because, you see, the
ext4 is also an implementation of the extended f/s format, and those
field assignments have already been made.

> All overlapping field issues can be resolved.

As long as you are willing to say that, then sure, let's work towards
that goal.

> It makes me very happy that you've studied Next3 enough to be able to
> make this almost correct observation.
> I do plan to use indirect mapped snapshot files when I merge them to Ext4.
> The only place that extent mapped files break the snapshots design is
> when doing move-on-write
> when writing in-place to extent mapped file.
> Should the extent be broken into 2 extents + single block and then
> move the block to snapshot?
> Should the block be copied-on-write instead of moved-on-write and pay
> the performance penalty?

If you do the "move-on-write" trick, you just have to split the extent
and do a COW of the extent tree and/or the inode.  So for a single
block, the performance hit the same, yes?  But in the long-run, it's
probably more efficient to do "move-on-write".

> There is an important design decision to make here.

Technically speaking, it's possible to do it both way, yes?  I'm not
sure why you consider this such a important design decision.  We can
even play games where for some files we might do copy-on-write, and
for some files, we do move-on-write.  It's always possible to check
the COW bitmaps to decide what had happened.

In any case, if this is all you have to do, I'm not sure why you said
it was fundamentally impossible to support extents with the Next3
design.

Best regards,

						- Ted
--
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