Symbol collisions in patch?

Symbol collisions in patch?

[Tom Oehser]

Hi-

I've been working on a new 2.x.x version of tomsrtbt, presumably -2.2.20.

I want to include support for ReiserFS, honest I do.

But...

1) There is a missing patch from the latest 2.2.19 patch that causes the
   kernel to oops when it is unmounted.  I have the patch now at least.

2) There are symbol collisions that prevent supporting reiser AND ext3fs,
   *even as a module*.  Come on, guys, symbol collisions between the two
   most popular journalling filesystems?  Pa-thetic...

3) There is no support for version 3.6 filesystems in 2.2.x, so, what good
   is reiser support on my rescue diskette, if 2.4.x users can't use it?

4) There seems to be no-one concerned about any of these issues, or
   working on them, or talking about them.

5) My guess is that reiser-4 will be 2.5.x or 2.6.x only, and never get
   back-supported to 2.4, much less 2.2.x.

All of this is a problem for me.

The bleeding-edge crowd may not be aware of it, but a new kernel is about
to be released- it is now up to 2.0.40-rc4.  That's right, 2.0.40-rc4.
And I can tell you that scsi drivers and network card drivers are still
being updated for that.  And the ext2 sparse-super and filesystem-type
fixes were backported to 2.0.x.

So, the rest of the world is still willing to devote *some* effort to
supporting 2.0.x, (and libc5, for that matter), and *plenty* of effort to
supporting 2.2.x, but it seems that reiser doesn't isn't or won't...

So, at the moment, I'm just going to put ext3 support in there, and put
fixing the patch and all the symbols and backporting 3.6 support on my
personal low-priority back burner...

-Tom

Re: Symbol collisions in patch?

[Oleg Drokin]

Hello!

On Tue, Apr 02, 2002 at 09:41:55PM -0500, Tom Oehser wrote:

> 2) There are symbol collisions that prevent supporting reiser AND ext3fs,
>    *even as a module*.  Come on, guys, symbol collisions between the two
>    most popular journalling filesystems?  Pa-thetic...

I believe this is ext3 problem, because reiserfs occupied these symbol first ;)
ext3 appeared a little bit later then reiserfs.

> 3) There is no support for version 3.6 filesystems in 2.2.x, so, what good
>    is reiser support on my rescue diskette, if 2.4.x users can't use it?

This is even documented. v3.6 format is for 2.4+ kernels only.
If you concerned that much about the issue and needs this v3.6 support,
you might try to convice Hans about that.
One of teh best ways to convice Hans to provice v3.6 support in 2.2 kernels
is to pay for the work (details are at http://www.namesys.com/support.html)

> 4) There seems to be no-one concerned about any of these issues, or
>    working on them, or talking about them.

It seems that most of reiserfs users are using v2.4 kernels.

> 5) My guess is that reiser-4 will be 2.5.x or 2.6.x only, and never get
>    back-supported to 2.4, much less 2.2.x.

I doubt for 2.2 support, but if 2.6 development will take another 2 years,
then 2.4 support might be provided ;) Also support for any kernel can be
provided if you'd pay for the porting. (even for non-Linux kernels)

> The bleeding-edge crowd may not be aware of it, but a new kernel is about
> to be released- it is now up to 2.0.40-rc4.  That's right, 2.0.40-rc4.

Yes, we are aware of that. ( kernel for hardcore paranoid crash-fearing people,
I presume)

> And I can tell you that scsi drivers and network card drivers are still
> being updated for that.  And the ext2 sparse-super and filesystem-type
> fixes were backported to 2.0.x.

Here is my opinition (may be Hans have another one), since there were no active
reiserfs users at 2.0 time, there is hardly any demand for reiserfs for linux
kernel 2.0.

> So, the rest of the world is still willing to devote *some* effort to
> supporting 2.0.x, (and libc5, for that matter), and *plenty* of effort to
> supporting 2.2.x, but it seems that reiser doesn't isn't or won't...

Well, with limited budget and workforce people tend to concentrate on things
that are important to them.

Bye,
    Oleg

Re: Symbol collisions in patch?

[Chris Mason]

On Wed, 2002-04-03 at 00:32, Oleg Drokin wrote:
> Hello!
> 
> On Tue, Apr 02, 2002 at 09:41:55PM -0500, Tom Oehser wrote:
> 
> > 2) There are symbol collisions that prevent supporting reiser AND ext3fs,
> >    *even as a module*.  Come on, guys, symbol collisions between the two
> >    most popular journalling filesystems?  Pa-thetic...
> 
> I believe this is ext3 problem, because reiserfs occupied these symbol first ;)
> ext3 appeared a little bit later then reiserfs.

Shrug, for 2.2.x, both filesystems grew within a short time of each
other.  I thought ext3 resolved the conflicts (at least they did in
2.4.x).

> 
> > 3) There is no support for version 3.6 filesystems in 2.2.x, so, what good
> >    is reiser support on my rescue diskette, if 2.4.x users can't use it?
> 
> This is even documented. v3.6 format is for 2.4+ kernels only.
> If you concerned that much about the issue and needs this v3.6 support,
> you might try to convice Hans about that.
> One of teh best ways to convice Hans to provice v3.6 support in 2.2 kernels
> is to pay for the work (details are at http://www.namesys.com/support.html)

Tom, putting the 3.6.x format into the 2.2.x code is a huge amount of
work.  It took us months to get things stable in 2.4.x.  If anyone on
the list wants to do the port, I'll supply beer for the party when
you're done.
 
> > So, the rest of the world is still willing to devote *some* effort to
> > supporting 2.0.x, (and libc5, for that matter), and *plenty* of effort to
> > supporting 2.2.x, but it seems that reiser doesn't isn't or won't...

We support the code we've written.  So, if someone finds a bug in 2.2.x
reiserfs, we fix it.  It is unlikely that new features (3.6.x, relocated
journals, non 4k block sizes) will be ported back to kernels before
2.4.x.

-chris

Re: Symbol collisions in patch?

[Oleg Drokin]

Hello!

On Wed, Apr 03, 2002 at 08:38:26AM -0500, Chris Mason wrote:
> > One of teh best ways to convice Hans to provice v3.6 support in 2.2 kernels
> > is to pay for the work (details are at http://www.namesys.com/support.html)
> Tom, putting the 3.6.x format into the 2.2.x code is a huge amount of
> work.  It took us months to get things stable in 2.4.x.  If anyone on
> the list wants to do the port, I'll supply beer for the party when
> you're done.

Offer the 2-way ticket to US, and I might think about your offer ;)

Bye,
    Oleg

Re: Symbol collisions in patch?

[Chris Mason]

On Wed, 2002-04-03 at 08:43, Oleg Drokin wrote:
> Hello!
> 
> On Wed, Apr 03, 2002 at 08:38:26AM -0500, Chris Mason wrote:
> > > One of teh best ways to convice Hans to provice v3.6 support in 2.2 kernels
> > > is to pay for the work (details are at http://www.namesys.com/support.html)
> > Tom, putting the 3.6.x format into the 2.2.x code is a huge amount of
> > work.  It took us months to get things stable in 2.4.x.  If anyone on
> > the list wants to do the port, I'll supply beer for the party when
> > you're done.
> 
> Offer the 2-way ticket to US, and I might think about your offer ;)
>

Grin, always specify the type of ticket.  You might end up stuffed into
a UPS express mail envelope.

-chris

Re: Symbol collisions in patch?

[Oleg Drokin]

Hello!

On Wed, Apr 03, 2002 at 09:02:30AM -0500, Chris Mason wrote:

> > Offer the 2-way ticket to US, and I might think about your offer ;)
> Grin, always specify the type of ticket.  You might end up stuffed into
> a UPS express mail envelope.

I was always thinking that sending people via mail/in baggage bay of
aircrafts was illegal. ;)

Bye,
    Oleg

Re: Symbol collisions in patch?

[Adrian Phillips]

>>>>> "Tom" == Tom Oehser <tom@toms.net> writes:

    Tom> 1) There is a missing patch from the latest 2.2.19 patch that
    Tom> causes the kernel to oops when it is unmounted.  I have the
    Tom> patch now at least.

I suppose the point here is that people who are interested in using a
journaled filesystem and 2.2 will probably be using reiserfs already -
it was the only journaled fs for 2.2 for quite a while.

    Tom> 2) There are symbol collisions that prevent supporting reiser
    Tom> AND ext3fs, *even as a module*.  Come on, guys, symbol
    Tom> collisions between the two most popular journalling
    Tom> filesystems?  Pa-thetic...

Uh, because ext3 has been more recently been ported to 2.2 and nobody
else has the two together before ?

    Tom> 3) There is no support for version 3.6 filesystems in 2.2.x,
    Tom> so, what good is reiser support on my rescue diskette, if
    Tom> 2.4.x users can't use it?

Well documented on the web page.

    Tom> 4) There seems to be no-one concerned about any of these
    Tom> issues, or working on them, or talking about them.

Probably because most everyone in the Linux world is focussed on newer
issues, 2.4 and later. As with most OSS projects it takes individuals
who are willing to spend the time to scratch their itch.

    Tom> All of this is a problem for me.

    Tom> The bleeding-edge crowd may not be aware of it, but a new

2.2 is bleeding edge - very funny.

    Tom> kernel is about to be released- it is now up to 2.0.40-rc4.
    Tom> That's right, 2.0.40-rc4.  And I can tell you that scsi
    Tom> drivers and network card drivers are still being updated for
    Tom> that.  And the ext2 sparse-super and filesystem-type fixes
    Tom> were backported to 2.0.x.

I think that this is rather riduculous, 2.0 is *extremely* old
now. 2.2 has been damn stable for many months and people have little
excuse for sticking with 2.0, except in very exceptional circumstances
IMO. Now if people who NEED this stuff are willing to backport it then
all power to them but you can't just appear on a mailing list and
start complaining at why this project hasn't done the same; if you
don't like it then start coding, if you don't have time then by all
means ask but don't whine.

    Tom> So, the rest of the world is still willing to devote *some*
            ^^^^
a small part of

    Tom> effort to supporting 2.0.x, (and libc5, for that matter), and
    Tom> *plenty* of effort to supporting 2.2.x, but it seems that
    Tom> reiser doesn't isn't or won't...

Because nobody has had the itch to scratch.

Please, this kind of tone of email is rather unconstructive. There is
only so much time for doing projects whether personal or company
supported, the accusing tone that some people have when that which
they require has not been implemented and for something in they
haven't contributed, either in time or money, is a bit sickening to
me.

Sincerely,

Adrian Phillips

-- 
Your mouse has moved.
Windows NT must be restarted for the change to take effect.
Reboot now?  [OK]

RE: Symbol collisions in patch?

[Adam Goryachev]

> The bleeding-edge crowd may not be aware of it, but a new kernel is about
> to be released- it is now up to 2.0.40-rc4.  That's right, 2.0.40-rc4.
> And I can tell you that scsi drivers and network card drivers are still
> being updated for that.  And the ext2 sparse-super and filesystem-type
> fixes were backported to 2.0.x.

If anyone was paranoid enough to *not* move up past 2.0.x then surely they
would be paranoid enough to *not* use something so modern as a journalled
filesystem which has only just been written and simply 'back-ported'... I
mean, if the 2.2.x kernels are not tested well enough, then surely the
reiserfs code has not been tested well enough???

> So, the rest of the world is still willing to devote *some* effort to
> supporting 2.0.x, (and libc5, for that matter), and *plenty* of effort to
> supporting 2.2.x, but it seems that reiser doesn't isn't or won't...

Why spend the next 6 months/12 months (I have no idea how long) developing
support for 2.0 and 2.2 kernels with reiserfs when by that stage, even the
super paranoid will have moved to 2.2 .... OK, there might still be 2 users
left, but really, is it worth a few hundred people working on code that will
be used by only one or two people ??

> So, at the moment, I'm just going to put ext3 support in there, and put
> fixing the patch and all the symbols and backporting 3.6 support on my
> personal low-priority back burner...

Fine, but since what is supported by 2.2 that is not supported in 2.4?? ie,
why would you build a rescue disk (ie assume this is supposed to be a one size
fits all rescue disk) based on a 2.2 kernel and not use a 2.4 kernel???

Surely at the point where one is looking for a rescue disk, you are not hugely
concerned about stability, all you want is enough to mount your disks, and
fixup whatever issue is stopping you from booting your standard kernel?

Regards,
Adam

RE: Symbol collisions in patch?

[Tom Oehser]

> If anyone was paranoid enough to *not* move up past 2.0.x then surely they

Paranoia likely has nothing to do with it- think about embedded systems,
there are still situations where *1.x* kernels are in use on 2-megabyte
machines.

> Why spend the next 6 months/12 months (I have no idea how long) developing
> support for 2.0 and 2.2 kernels with reiserfs when by that stage, even the

It wouldn't take that long to fix the symbol collisions and apply the
known-missing patch.  It probably wouldn't take that long to backport the
3.6 stuff.

> left, but really, is it worth a few hundred people working on code that will
> be used by only one or two people ??

Hyperbole.  It wouldn't take hundreds of people to make the 2.2.20 patch
stable.  Fixing the symbol collisions and applying the umount locking?
Hundresds of people and 6/12 months?

> Fine, but since what is supported by 2.2 that is not supported in 2.4?? ie,
> why would you build a rescue disk (ie assume this is supposed to be a one size
> fits all rescue disk) based on a 2.2 kernel and not use a 2.4 kernel???

If the kernel wasn't bloating by hundreds of K for a feature-equivalent
build, of course I would use 2.4.  With the exact same feature set, a 2.4
kernel is much much bigger,  approaching *twice the size* of a 2.0 kernel.

Look, not backporting 3.6 support to 2.2.x, I can understand, if not agree
with.  Nor do I agree it would take "6 months/12 months" or "a few hundred
people working on code".  But not maintaining the basic usability, leaving
in the oops producing bugs, not fixing the symbol collisions- that makes
me skittish.  You should just take the 2.2.x patches completely off the
web site, not leave them up for people to oops.

-Tom

Re: Symbol collisions in patch?

[Oleg Drokin]

Hello!

On Wed, Apr 03, 2002 at 06:51:23AM -0500, Tom Oehser wrote:

> > Why spend the next 6 months/12 months (I have no idea how long) developing
> > support for 2.0 and 2.2 kernels with reiserfs when by that stage, even the
> It wouldn't take that long to fix the symbol collisions and apply the
> known-missing patch.  It probably wouldn't take that long to backport the
> 3.6 stuff.

Symbol collisions are not going to be fixed at reiserfs side.
Symbol collisions were introduced by ext3 folks.

Bye,
    Oleg

Re: Symbol collisions in patch?

[Chris Mason]

On Tue, 2002-04-02 at 21:41, Tom Oehser wrote:

> So, at the moment, I'm just going to put ext3 support in there, and put
> fixing the patch and all the symbols and backporting 3.6 support on my
> personal low-priority back burner...

It would also be hugely useful to have reiserfsck included on  your
disk.  reiserfsck can't do extensive tree rebuilds with the FS mounted
(even readonly), so being able to boot off floppy and rebuild things
would be cool.

-chris