On Sat, May 8, 2010 at 1:48 PM, Theodore Tso wrote: > > 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. > Next3 is another implementation of the extended f/s format. Next3 is a superset of ext3 plus snapshots. > > 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. Next3 is backward and forward compatible with ext3. Next3 path to e2fsprogs doesn't treat it as a different file system format. All overlapping field issues can be resolved. > > 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. It is _practically_ possible to support the snapshot features/fields in e2fsprogs today and to add the support for the same snapshot features/fields to Ext4 later. > 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.) > 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? There is an important design decision to make here. Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
