Collapse ext2 and 3 please

Collapse ext2 and 3 please

[John Richard Moser]

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

Re: Collapse ext2 and 3 please

[Helge Hafting]

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.

> 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

Re: Collapse ext2 and 3 please

[David van Hoose]

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

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

Re: Collapse ext2 and 3 please

[Christoph Hellwig]

On Fri, Jun 25, 2004 at 07:30:40AM -0400, David van Hoose wrote:
> If ext2 and ext3 are different filesystems, why does my kernel panic if 
> I include ext3 in the kernel make ext2 a module?

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

Re: Collapse ext2 and 3 please

[David van Hoose]

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.

Christoph Hellwig wrote:
> On Fri, Jun 25, 2004 at 07:30:40AM -0400, David van Hoose wrote:
> 
>>If ext2 and ext3 are different filesystems, why does my kernel panic if 
>>I include ext3 in the kernel make ext2 a module?
> 
> 
> My kernel doesn't, must be a problem in front of the computer.
> 
> 

Re: Collapse ext2 and 3 please

[Matthew Garrett]

David van Hoose wrote:

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

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

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: Collapse ext2 and 3 please

[David van Hoose]

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

Regards,
David

Anton Altaparmakov wrote:
> On Fri, 2004-06-25 at 12:50, David van Hoose wrote:
> 
>>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.
> 
> 
> Have a look in /etc/fstab, does it say ext3 or ext2 for your root
> partition?  If it says ext2 then of course it panics and Christoph was
> right.  (-;
> 
> Best regards,
> 
> 	Anton

Re: Collapse ext2 and 3 please

[Matthew Garrett]

David van Hoose wrote:
>All ext3 partitions are labeled as ext3. It still panics.

The kernel doesn't read fstab. Try 

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

-- 
Matthew Garrett | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org

Re: Collapse ext2 and 3 please

[David van Hoose]

[-- Attachment #1: Type: text/plain, Size: 717 bytes --]

Anton Altaparmakov wrote:
> On Fri, 2004-06-25 at 13:05, David van Hoose wrote:
> 
>>All ext3 partitions are labeled as ext3. It still panics.
> 
> 
> Could you show your /etc/fstab?  (Only the root fs entry is of
> interest.)
> 
> And the output of: tune2fs -l /dev/hda1 | grep -i journal
> 
> You need to replace /dev/hda1 with your actual boot device...
> 
> Best regards,
> 
> 	Anton

[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

[-- Attachment #2: fstab --]
[-- Type: text/plain, Size: 816 bytes --]

/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

Re: Collapse ext2 and 3 please

[Tigran Aivazian]

On Fri, 25 Jun 2004, David van Hoose wrote:
> [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
> 

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

Re: Collapse ext2 and 3 please

[David van Hoose]

Tigran Aivazian wrote:
> On Fri, 25 Jun 2004, David van Hoose wrote:
> 
>>[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
>>
> 
> 
> 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?

I use Grub.
root=/dev/sda2

Regards,
David

Re: Collapse ext2 and 3 please

[Rik van Riel]

On Fri, 25 Jun 2004, David van Hoose wrote:

> fstab is attached.

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

Re: Collapse ext2 and 3 please

[Christoph Hellwig]

On Fri, Jun 25, 2004 at 07:50:42AM -0400, David van Hoose wrote:
> 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.

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?

Re: Collapse ext2 and 3 please

[David van Hoose]

Christoph Hellwig wrote:
> On Fri, Jun 25, 2004 at 07:50:42AM -0400, David van Hoose wrote:
> 
>>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.
> 
> 
> 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

Re: Collapse ext2 and 3 please

[Richard B. Johnson]

On Fri, 25 Jun 2004, David van Hoose wrote:

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

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.

Re: Collapse ext2 and 3 please

[Philip R. Auld]

Rumor has it that on Fri, Jun 25, 2004 at 07:50:42AM -0400 David van Hoose said:
> 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.
> 


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

Cheers,

Phil


> Regards,
> David
> 
> PS. Shut up with the cheap insults. I have empirical evidence supporting 
> my claim. Meaning there exists a bug somewhere.
> 
> Christoph Hellwig wrote:
> > On Fri, Jun 25, 2004 at 07:30:40AM -0400, David van Hoose wrote:
> > 
> >>If ext2 and ext3 are different filesystems, why does my kernel panic if 
> >>I include ext3 in the kernel make ext2 a module?
> > 
> > 
> > My kernel doesn't, must be a problem in front of the computer.
> > 
> > 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: Collapse ext2 and 3 please

[David van Hoose]

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

Regards,
David

Philip R. Auld wrote:
> Rumor has it that on Fri, Jun 25, 2004 at 07:50:42AM -0400 David van Hoose said:
> 
>>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.
>>
> 
> 
> 
> Make sure any initrd you are using is not ext2 based.
> 
> Cheers,
> 
> Phil
> 
> 
> 
>>Regards,
>>David
>>
>>PS. Shut up with the cheap insults. I have empirical evidence supporting 
>>my claim. Meaning there exists a bug somewhere.
>>
>>Christoph Hellwig wrote:
>>
>>>On Fri, Jun 25, 2004 at 07:30:40AM -0400, David van Hoose wrote:
>>>
>>>
>>>>If ext2 and ext3 are different filesystems, why does my kernel panic if 
>>>>I include ext3 in the kernel make ext2 a module?
>>>
>>>
>>>My kernel doesn't, must be a problem in front of the computer.
>>>
>>>
>>

Re: Collapse ext2 and 3 please

[Tigran Aivazian]

# 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

On Fri, 25 Jun 2004, David van Hoose wrote:

> That could be a problem. How do I check its configuration?
> 
> Regards,
> David
> 
> Philip R. Auld wrote:
> > Rumor has it that on Fri, Jun 25, 2004 at 07:50:42AM -0400 David van Hoose said:
> > 
> >>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.
> >>
> > 
> > 
> > 
> > Make sure any initrd you are using is not ext2 based.
> > 
> > Cheers,
> > 
> > Phil
> > 
> > 
> > 
> >>Regards,
> >>David
> >>
> >>PS. Shut up with the cheap insults. I have empirical evidence supporting 
> >>my claim. Meaning there exists a bug somewhere.
> >>
> >>Christoph Hellwig wrote:
> >>
> >>>On Fri, Jun 25, 2004 at 07:30:40AM -0400, David van Hoose wrote:
> >>>
> >>>
> >>>>If ext2 and ext3 are different filesystems, why does my kernel panic if 
> >>>>I include ext3 in the kernel make ext2 a module?
> >>>
> >>>
> >>>My kernel doesn't, must be a problem in front of the computer.
> >>>
> >>>
> >>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: Collapse ext2 and 3 please

[David van Hoose]

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

Tigran Aivazian wrote:
> # 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
> 

Re: Collapse ext2 and 3 please

[John Richard Moser]

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

Re: Collapse ext2 and 3 please

[Sean Neakums]

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.

Re: Collapse ext2 and 3 please

[Timothy Miller]

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


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.

Re: Collapse ext2 and 3 please

[Sean Neakums]

Timothy Miller <miller@techsource.com> writes:

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

Re: Collapse ext2 and 3 please

[Timothy Miller]

Sean Neakums wrote:
> Timothy Miller <miller@techsource.com> writes:
> 
> 
>>Sean Neakums 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.
>>
>>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.

Re: Collapse ext2 and 3 please

[R. J. Wysocki]

On Friday 25 of June 2004 20:41, Timothy Miller wrote:
> Sean Neakums wrote:
> > Timothy Miller <miller@techsource.com> writes:
> >>Sean Neakums 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.
> >>
> >>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

Re: Collapse ext2 and 3 please

[Sean Neakums]

"R. J. Wysocki" <rjwysocki@sisk.pl> writes:

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

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.

Re: Collapse ext2 and 3 please

[R. J. Wysocki]

On Friday 25 of June 2004 22:50, Sean Neakums wrote:
> "R. J. Wysocki" <rjwysocki@sisk.pl> writes:
> > 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?
>
> 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

Re: Collapse ext2 and 3 please

[Andrew Morton]

Sean Neakums <sneakums@zork.net> 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.

Much pain, little gain.

Re: Collapse ext2 and 3 please

[John Richard Moser]

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

Andrew Morton wrote:
| Sean Neakums <sneakums@zork.net> 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-----

Re: Collapse ext2 and 3 please

[Pascal Schmidt]

On Fri, 25 Jun 2004 21:00:23 +0200, you wrote in linux.kernel:

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

Well, if the initrd (which is a ramdisk with a filesystem on it) is ext2,
you need ext2 in the kernel. It has nothing to do with the root filesystem
type, really. Journalling on an initrd makes no sense, so ext2 is
actually a sensible choice there.

-- 
Ciao,
Pascal