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

On May 8, 2010, at 1:43 AM, Amir G. wrote:

> 1. No features are added to Ext3, so there is no concern for the
> stability of Ext3.
> The feature is added as a new f/s, with the slight overhead of
> duplicate code in the
> kernel tree and an extra loadable module in the system.

This is where it's important to understand exactly what is meant by a ***file
system***.   Are you referring to the format, or the implementation?   The
way I've always treated it, and it's the way I believe most of the ext234
developers have treated it is, that what users call ext2, ext3, and ext4 are
different _implementations_ of the same _file_ _system_ [format].    That is
to say, ext4 simply happens to be a fuller, more complete implementation  of
the same file system as ext2 and ext3.   Ext2 doesn't support certain
features such as journaling and directory indexing; ext3 doesn't support some
advanced features such as delayed allocation and extents, and requires that
the journal always be present.   Ext4 is a superset of ext2 plus ext3 plus
delayed allocation, extents, a multi-block allocator, and a few other new
features.   But they are all the same file system.

Nor are they the only implementations of that file system.  The BSD file
systems have a compatible (although feature-restricted) implementation, which
was independently implemented.  So does the GNU HURD.   And there are others.
And note that all of these folks all use the same userspace utilities,
e2fsprogs, for all of these various implementations: BSD, GNU HURD, and the
Linux implementations of ext2, ext3, and ext4 all use the same set of tools:
mke2fs, e2fsck, tune2fs, debugfs, and so on.

The same this is true for NTFS.   There are features in NTFS that you will
find in Windows Vista that don't exist in Windows NT or Windows Vista.  But
everybody treats them as the same file system, even though they have more
advanced features in newer versions of the operating system.

The "ext" in ext2 stands for "extended", as in the "the second extended file
system" for Linux.   It perhaps would be better if we had used the term
"extensible", since that's the main thing about ext2/3/4 that has given it so
much staying power.  We've been able to add, in very carefully backwards and
forwards compatible way, new features to the file system format.  This is why
I object to why Next3 uses some fields that overlaps with ext4.   It means
that e2fsprogs, which supports _one_ and _only_ _one_ file system format,
will now need to support two file system formats.  And that's not something I
want to do.

Put another away, it should be possible to add your "Next3" snapshots to
ext4.  Even if today, no one has the time and energy to do the work, it is
something that should be _theoretically_ possible.  In another e-mail
message, you've made the claim: "Unfortunately, merging Next3 snapshots
feature into Ext4 is not an easy task, because extent mapped files break
the design concepts of Next3 snapshots."  But aside from stealing fields
already assigned to various features supported by ext4, this isn't true!  I
don't see anything that fundamentally incompatible with Next3 and
extent-mapped files.  (Unless you mean that the snapshot file might not be
as efficiently stored using extent-mapped files, but [a] it's not clear the
lack of efficiency will matter, since most files are contiguously stored,
and there can be over 380 extents in a extent tree leaf block, and [b] we
could always use an indirect block mapped file for the snapshot file ---
ext4 is fully backwards compatible with ext2, so you can use an old-style
direct/indirect block mapped file for the snapshot if you really wanted.)

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