-----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-----
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
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
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.
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.
>
>
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 | [email protected]
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
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?
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 | [email protected]
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
/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
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.
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
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.
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
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 [email protected]
> 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
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.
>>>
>>>
>>
# 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
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
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.
Timothy Miller <[email protected]> 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".
Sean Neakums wrote:
> Timothy Miller <[email protected]> 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.
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
>
On Friday 25 of June 2004 20:41, Timothy Miller wrote:
> Sean Neakums wrote:
> > Timothy Miller <[email protected]> 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
"R. J. Wysocki" <[email protected]> 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.
On Friday 25 of June 2004 22:50, Sean Neakums wrote:
> "R. J. Wysocki" <[email protected]> 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
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.
Much pain, little gain.
-----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-----
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
-----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-----