Just to summarize the discussion a bit:
- ReiserFS 3.5 is designed for Linux2.2, and it is stable
- ReiserFS 3.6 is designed for Linux2.4, and it is stable
- ReiserFS 3.6 kernel code can read and write ReiserFS 3.5 filesystems without
making it incompatible
- ReiserFS 3.6 will be maintained at least as long as Linux2.4 will be current
(for the next 18 months)
- Most new features in Linux2.4 have to be implemented downward compatible (e.g.
the new feature won't be available to older version, but older versions of 2.4.x
will access 2.4.y)
- New features which require incompatibilities are introduced in Linux2.5
- 2.5|2.6 code will access 2.4 filesystems without incompatibilites, as 2.4 code
can access 2.2 filesystems.
- The ReiserFS team will backport ReiserFS3.6 to Linux2.2
- Every ReiserFS version will not attempt to convert to a new, incompatible format
with default options.
There are following conclusions:
- ReiserFS in Linux2.4.x will not make format changes so that it won't be readable
in Linux2.4.y
- ReiserFS in Linux2.5 has the development freedom every other 2.5 component has,
including format changes (if they are really needed)
- common Linux user will benefit from ReiserFS in 2.4 with no problems, but all
its advantages
- For users which are in the 2.2->2.4 upgrade timeframe and need to switch back
and forth, they can do this safely by using the ReiserFS3.5 disk format,
which is currently supported by ReiserFS for Linux2.2 and Linux2.4. Maybe
mkreiserfs should create the old format (flag) by default, so that a partition
created
in 2.4 for experiments can be used in 2.2 (when users have reasons to downgrade)
without problems.
- Once ReiserFS 3.6 support for Linux2.2 is stable, mkreiserfs can create the new
format by default. (This is an example for why utils within the kernel are not the
worst idea. ;o))
Correct me please if I'm wrong, but I do not see any problems with reiserfs in
2.2, 2.4 and 2.5 times.
Xuân. :o)
P.S.: For the possible incompatible changes in 2.5, maybe there is an elegant
solution for incompatible down|upgrading: the planned repacker can decide in which
format it wants to write the data it processes. But once a cross-format-repacker
is working, there is also the "traditional" way of converting by using LVM: do
{Shrink the one partition, enlarge the other, copy} while (!old.isEmtpy());
Richard Torkar wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tue, 6 Jun 2000, David Luyer wrote:
>
> >
> > Richard Torkar wrote:
> >
> > > I on the other hand don't see the problem, since a decent coder can use
> > ^^^^^^^^^^^^
> > > patch/diff so applying the reiserfs patches isn't hard to do...
> > >
> > > Please give some good reasons why applying reiserfs in 2.4.* would be a
> > > good idea. And I don't mean that sarcasticly I mean it out of curiousity.
> >
> > You assume everyone who wants to use reiserfs is a "decent coder"?
>
> No, I do not assume that. I assume that he can patch a kernel tree. If he
> can't do that then I would say that he would be pretty lost when it comes
> to dealing with formatting a HD.
>
> Journaling fs might sound very cool (and it is :) but putting it in the
> kernel means basically (even if it says EXPERIMENTAL) that new users who
> compile their first kernels might try that and after a while *fsck* their
> HD permanentally, which leads to ppl screaming that Linux sucks. And
> nobody wants that.
>
> **SNIPPED**
> >
> > Keeping it out of the mainstream kernel keeps it away from the mainstream
> > users. People who know how to run a Linux system in general but have never
> > actually had to compile anything (since Debian, RedHat, etc do such a good
> > job of making things available in packages). What the distributions ship in
> > their kernels is strongly influenced by what is in the base kernel.
>
> Agreed. That is a *good* argument. :)
>
> Regards
> Richard Torkar
> - ---
> Linux 2.4.0-test1-ac8, 2034.89 BogoMIPS
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.1 (GNU/Linux)
> Comment: Made with pgp4pine 1.75
>
> iD8DBQE5O/c4USLExYo23RsRAplIAKDY5eunYpGXYGmgvrLaYbGFgdM96gCgqo22
> TOTMKHi4M9e8B2plDubvayo=
> =tQZM
> -----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:22 EST