[lkml]   [2004]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Collapse ext2 and 3 please
    If ext2 and ext3 are different filesystems, why does my kernel panic if 
    I include ext3 in the kernel make ext2 a module?


    Helge Hafting wrote:
    > John Richard Moser wrote:
    >> Hash: SHA1
    >> I know this has been mentioned before, or at least I *hope* it has.
    > Take a look at history. Linus said that creating a journalled fs was
    > fine, but they had to make it a new fs so as to not make ext2 unstable
    > while working on it. Therefore - ext3. Now ext3 was based on ext2
    > so it basically started out as a copy.
    >> ext2 and ext3 are essentially the same, aren't they? I'm looking at a
    >> diff, and other than ext2->ext3, I'm seeing things like:
    >> - - mark_inode_dirty(inode);
    >> + ext3_mark_inode_dirty(handle, inode);
    >> and thinking
    >> - - mark_inode_dirty(inode);
    >> +#ifdef CONFIG_EXT2_JOURNALED
    >> + if (fs->journaled)
    >> + extjnl_mark_inode_dirty(handle, inode);
    >> + else
    >> +#endif
    >> + mark_inode_dirty(inode);
    >> would have been so much more appropriate.
    > No, because:
    > 1. Code withg lots of #ifdefs isn't popular here. So don't suggest it,
    > because no argument will win this one.
    > 2. Did it ever occur to you that some people want to support both
    > ext2 and ext3 with the same kernel. Impossible with your scheme,
    > and don't say "nobody needs that".
    > 3. ext3 may evolve differently from ext2 with time. Common code
    > makes people do things in suboptimal ways in order to keep
    > commonality. There is _no_ commonality pressure when the
    > sources are separate. ext3 developers are free to change their
    > code in ways that could break operation of the non-journalling ext2.
    > And vice-versa- ext2 is free do use ordering optimizations incompatible
    > with journalling.
    > 4. "Appropriate" doesn't matter. Readability and maintainability does.
    > 5. Linus demanded two fs'es in this case, so there is no discussion.
    >> I see entire functions that
    >> are dropped and added; the dropped can stay, the added can be added,
    >> they can be used conditionally. I also see mostly code that just was
    >> copied verbatim, or was s/EXT2/EXT3/ or s/ext2/ext3/ . That's just not
    >> appropriate.
    > This is not much of a problem - a few kB wasted on keeping some
    > identical copies of code. You might be able to establish a
    > ext23_common.c, _if_ you can prove that the stuff therein really
    > won't ever be different in ext2 and ext3.
    >> The ext2 driver can even load up ext3 partitions without using the
    >> journal, if it still behaves like it did in 2.4.20. I say collapse them
    >> in on eachother.
    > This was very useful during initial development, when ext3 couldn't
    > really be trusted. It is still useful because it allows easy conversion
    > of existing filesystems, and a single fsck. Compatibility might break
    > someday though.
    > The fs code may take very different approaches with time anyway,
    > even if the disk layout remains compatible.
    > Helge Hafting
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:04    [W:0.025 / U:32.852 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site