On Sat, May 08, 2010 at 06:07:40PM +0200, Amir G. wrote:
quoted text
> 
> 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.

quoted text
> All overlapping field issues can be resolved.

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


quoted text
> 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".

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html