Collapse ext2 and 3 please

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I know this has been mentioned before, or at least I *hope* it has.

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

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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA22BbhDd4aOud5P8RAqsqAJ9hVAgMnKIHzXNx1NIs7cwYbLvfrwCfU8D2 Q+NLucNYfQRft3Fd1Q0HpPE=
=Vmkg
-----END PGP SIGNATURE-----

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.

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.

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.

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

If ext2 and ext3 are different filesystems, why does my kernel panic if I include ext3 in the kernel make ext2 a module?

Regards,
David

My kernel doesn't, must be a problem in front of the computer.

yeah.. Really. Here's what I do.

I have ext3 partitions, so I decided if they are different partitions, then I can compile my kernel with ext2 as a module and ext3 builtin. So I do it and reboot. Panic! Reason? Cannot find filesystem for the root partition.
The error is in the kernel itself either way. Pick your reason.
1) ext3 is identified as ext2 on bootup.
2) There is no fallback to ext3 if ext2 is not found.

I'll check this again to be sure on a 2.6 kernel later today, but as far as 2.4 is concerned my kernel panics.

Regards,
David

PS. Shut up with the cheap insults. I have empirical evidence supporting my claim. Meaning there exists a bug somewhere.

Are you really, really, really sure that your root partition is ext3? Really?

Matthew Garrett | [email protected]

All ext3 partitions are labeled as ext3. It still panics.

Regards,
David

The kernel doesn't read fstab. Try

tune2fs -l /dev/whatever | grep -i journal

Matthew Garrett | [email protected]

[root@bahamut root]# /sbin/tune2fs -l /dev/sda2 | grep -i journal

Filesystem features:      has_journal filetype needs_recovery sparse_super
Journal inode:            8
Journal backup:           inode blocks

fstab is attached.
I have separate partitions for / and /boot, however, the outputs are all the same.

Regards,
David

/dev/sda2		/                       ext3    defaults        1 1
/dev/sda1		/boot                   ext3    defaults        1 2

/dev/sda5 swap swap defaults 0 0
/dev/sda6 /home ext3 defaults 1 3
/dev/sda7 /mnt/data auto sync,uid=root,gid=shared,umask=007 1 3
/dev/sda8 /mnt/mp3s auto sync,uid=root,gid=shared,umask=007 1 3

/dev/hda1		/mnt/backup		ext3    defaults        1 4
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /proc                   proc    defaults        0 0
none                    /dev/shm                tmpfs   defaults        0 0
/dev/cdrom              /mnt/cdrom              udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0                /mnt/floppy             auto    noauto,owner,kudzu 0 0

Ok, fine, and what does your /etc/lilo.conf or /etc/grub.conf look like? Are you passing "root=/dev/sda2" or "root=LABEL=/" to the kernel?

Kind regards
Tigran

I use Grub.
root=/dev/sda2

Regards,
David

And not very relevant, look in /proc/mounts instead.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Doesn't make sense. The kernel just tries all registered filesystems for the rootfs until one clames it. It means you either:

- don't actually have ext3 in the kernel or
- the filesystems actually is ext2 and not ext3

Try calling debugfs /dev/$ROOTDEVICE and then typing features, what does it say?

[root@bahamut root]# /sbin/debugfs /dev/sda2
debugfs 1.35 (28-Feb-2004)

debugfs:  features
Filesystem features: has_journal filetype needs_recovery sparse_super
debugfs:  quit

[root@bahamut root]#

Is that sufficient for you?

Regards,
David

If you make the root file-system, or any part of it, a module, then the module must be loaded before the kernel attempts to mount the root file-system. This is normally done using initrd. You need to find out how to reconfigure initrd to handle your changes. This varies between vendors and has nothing to do with the kernel. In fact, when you see the message about being unable to mount the root file-system, it means that the kernel was running fine but ran out of things to do on startup because somebody, probably you, failed to provide an available file-system to mount so it could continue the startup by executing init.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.26 on an i686 machine (5570.56 BogoMips).
Note 96.31% of all statistics are fiction.

Make sure any initrd you are using is not ext2 based.

Cheers,

Phil

Philip R. Auld, Ph.D.  	        	       Egenera, Inc.    
Software Architect                            165 Forest St.
(508) 858-2628                            Marlboro, MA 01752

That could be a problem. How do I check its configuration?

Regards,
David

# gzip -dc /boot/initrd-2.4.21-15.EL.img | file -
standard input:              Linux rev 1.0 ext2 filesystem data

Make sure you use the correct filename for your initrd image (check /etc/grub.conf to find out which one is used).

Kind regards
Tigran

Thank you.
It says ext2. Based on other messages, I look at /sbin/mkinitrd.
It looks to me that RedHat/Fedora are pretty dumb making stupid assumptions about the fs type instead of looking at the filesystem types that root has setup in fstab.
I've patched my mkinitrd script to check the fs type of the root partition according to /proc/mounts. This should work unless someone is overriding mkinitrd to build an initrd for a foreign system or changing their root partition. To fix that, I've added an command-line option to specify the fs type of the root partition.

Thanks very very much.
Sorry for the error. I assumed too much about RedHat.

Thanks,
David

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Helge Hafting wrote:

| John Richard Moser wrote:
|
|> -----BEGIN PGP SIGNED MESSAGE-----
|> 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.
|

Yep. What's your point? It started out that way; nobody grabbed it and said "Let's make two copies."

|> 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:
*snip*

|
|
| No, because:
| 1. Code withg lots of #ifdefs isn't popular here.  So don't suggest it,
|    because no argument will win this one.

So don't then; maybe we should consider dropping the journal's togglability.

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

I'd thought about this.

kernel /boot/bzImage-2.6.7 root=/dev/hda5 ext3_root_journal=none

That'd be specific enough syntax to make the root mount at boot time mount just as ext2 would, without makign all ext* partitions nonjournaled (with appropriate code).

As for mounting, data=nojournal or data=direct or whatever flavor you like could be used to force no journal, just like mounting an ext3 as an ext2.

If no journal is found, it can load as nonjournaled/ext2 automatically.

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

if (!journaled)
extfs_do_ordering()

Some things look like hell with the diffs; there's blocks where blocks of 3-4 lines are different, then one similar. Either code has to be reordered to make it cleaner; or some lines will have to be duplicated, which I'd rather not do because it makes for maintenance nightmares.

| 4. "Appropriate" doesn't matter. Readability and maintainability does.

I have no argument; however, the current code organization may be altered to conform to this assertion if necessary.

| 5. Linus demanded two fs'es in this case, so there is no discussion.

You said above, "so as to not make ext2 unstable while working on it." I do not know what Linus said exactly; but I interpret this the way you stated as, "I don't want you hacking new sh*t into our primary filesystem and having it blow up in our faces while you get your sketchy design refined out to something workable." It's already workable now, so if I'm interpreting this right, it should be fine.

I will say this: that is a brilliant suggestion. Somebody should copy fs/ext3 to fs/extfs, merge in the missing parts of ext2, make {ext,EXT}{2,3}* {extfs,EXTFS}*, and try to stabalize it first. This will inflame the issue at hand first, by adding another redundant filesystem to the tree; but if people use it over ext2+ext3, perhaps the others will be depricated eventually, and fall off the tree. If not, maybe they'll junk it; that's always a risk.

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

Don't forget that I have to compile the same shit twice; make sure the appropriate module is in my kernel; and switch between them to use on different filesystems. This even leaves no room for mount -o remount,data=nojournal if someone was so inclined to lock the fs, flush the journal, switch journaling off, and unlock.

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

I see ext3 as ext2 with an added journal, and to my understanding this is exactly what it is. ext2 was supposed to have transparent compression or something at some point; when (if) it gets it, it will have to be merged into ext3 as well.

Also, from Documentation/filesystems/ext3.txt:

ext3 is ext2 filesystem enhanced with journalling capabilities.

As well as:

Specification
=============
ext3 shares all disk implementation with ext2 filesystem, and add transactions capabilities to ext2. Journaling is done by the Journaling block device layer.

| The fs code may take very different approaches with time anyway, | even if the disk layout remains compatible.

Optimization functions and such could be split out, and from what I've seen some code will have to be reordered to be more blocky to avoid a hell of if() blocks; but you can always conditionally call the different functions.

| Helge Hafting

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA3KZ7hDd4aOud5P8RAonLAJ984zGlJtZ83rS5/zKPxS83UEA+qgCdEx9Q WDnj+bFbc6hP8OHGL/1imN8=
=M3kf
-----END PGP SIGNATURE-----

I seem to remember somebody, I think maybe Andrew Morton, suggesting that a no-journal mode be added to ext3 so that ext2 could be removed. I can't find the message in question right now, though.

As an option, that might be nice, but if everyone were to start using ext3 even for their non-journalled file systems, the ext2 code would be subject to code rot.

My paraphrase is at fault here. In the above, "removed" == "removed from the kernel tree".

I understood that.

Let me be more clear. I agree with other people's comments to the effect that ext2 and ext3 have different goals and therefore different and potentially incompatible optimizations. If ext3 had a mode that made it equivalent to ext2, which encouraged people to only compile in ext3 even for ext2 partitions (to save on kernel memory), then future ext2 code bases would get less use and therefore less testing and therefore more code rot.

It is reasonable to allow the redundancy between ext2 and ext3 in order to allow them to diverge. This kind of future-proofing mentality underlies the reasons why kernel developers don't want to completely stablize the module ABI, for example.

Let me add my 2c, please.

I think that the most of users will use ext3 or reiserfs anyway, unless they actually _prefer_ ext2 for some reasons (let's face it: the most of users just follow the distribution defaults and the most of distributors set either ext3 or reiserfs as a default). This, however, confines the use of ext2 to a (relatively) small group of users having special needs and means that the future ext2 code will get less testing in any case, just like old device drivers do (eg. old CD-ROM drivers ;-)).

I'm not for collapsing the ext2 and ext3 code bases, but IMHO your argument does not apply.

I think that the good reason for keeping both ext* code bases in the kernel tree is that _there_ _are_ _some_ people who will need ext2 for some purposes, so why should we pull the carpet from under them?

Yours,
rjw

----------------------------
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.
-- Richard P. Feynman

An ext3 that supports no-journal operation can surely register itself as both ext2 and ext3 and leave userspace none the wiser.

I don't think anybody wants to pull any carpets out from under anyone.

Sorry, I've been too offensive.

IMO, if ext2 is kept separate, the development of it may be focused on different user needs than the development of ext3 is focused on. It's worth doing as long as there's someone who will prefer ext2 to ext3 and someone who's interested in working on ext2 itself. That's my point.

Yours,
rjw

----------------------------
For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.
-- Richard P. Feynman

I think it could be done, mainly as a kernel-space-saving exercise. But the two filesystems are quite different nowadays.

ext2 uses per-inode pagecache for directories, ext3 uses blockdev pagecache. The truncate algorithms are significantly different. Other stuff.

Much pain, little gain.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andrew Morton wrote:

| Sean Neakums <[email protected]> wrote:
|
|>I seem to remember somebody, I think maybe Andrew Morton, suggesting
|>that a no-journal mode be added to ext3 so that ext2 could be removed.
|>I can't find the message in question right now, though.
|
|
| I think it could be done, mainly as a kernel-space-saving exercise.  But
| the two filesystems are quite different nowadays.
|
| ext2 uses per-inode pagecache for directories, ext3 uses blockdev
| pagecache.  The truncate algorithms are significantly different. Other

stuff.
|

So why isn't it feasible to keep truncate algorithms and pagecache code separated while collapsing the rest? Same logic as i said in another reply:

if (journaled)
~ extfs_journaled_truncate();
else
~ extfs_nonjournaled_truncate();

| Much pain, little gain.

I understand this; but all work done is volunteer, so it'll only get done if someone wants to do it :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA3LnAhDd4aOud5P8RApugAJ45XGfdVGxVSEYsk/N55S4r5Qd+BACgi1vp cgv421B9Yxc3EX/TUv/nm+M=
=bZBQ
-----END PGP SIGNATURE-----