Re: mm vs. official for reiser4.

Re: mm vs. official for reiser4.

[Steven Cole]

On Friday 06 February 2004 10:38 am, Hans Reiser wrote:
> Until we have removed all bugs that we can hit with internal testing, we
> will produce snapshots for use with only one kernel branch.  I am
> guessing that more reiser4 testers will use Linus kernel than Morton's.
> Readers should correct me if I err.....

Only one kernel branch: Agree.
Linus vs Andrew's tree for reiser4: Andrew's tree.

If you look at the patch flow since 2.6.0, a large majority of patches 
come in via Andrew's -mm tree.  This has been the staging area for
new stuff, and this arrangement was explicitly addressed by Linus and
Andrew.

I've been doing testing lately _only_ with the -mm tree, and just today
got an oops while umounting a reiserfs v3 partition.  Andrew responded
with a one line fix within 30 minutes (the problem was not with reiserfs BTW).

I think you'll greatly increase the chances of getting reiser4 into 2.6 by making
it easy for Andrew to incorporate it into the -mm tree first.  Reiser4 may have to
sit in -mm for a couple of months, but at least it will be on Andrew's radar screen.

Steven

Last reiser4 snapshot is at: http://www.namesys.com/snapshots/2004.02.06/

[Nikita Danilov]

Hello,

new snapshot has been released. It is mainly bug-fixing release.

Take a look at the READ.ME for the list of known problems.

Nikita.

Re: Last reiser4 snapshot is at: http://www.namesys.com/snapshots/2004.02.06/

[Sander]

Hi Nikita,

Nikita Danilov wrote (ao):
> new snapshot has been released. It is mainly bug-fixing release.
> 
> Take a look at the READ.ME for the list of known problems.

There are two LATEST_IS files in the snapshots dir.

Btw, can you please make a snapshot against the -mm tree? I think that
would help to get it included in that tree.

Thanks for this release!

With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

Re: Last reiser4 snapshot is at: http://www.namesys.com/snapshots/2004.02.06/

[Nikita Danilov]

Sander writes:
 > Hi Nikita,
 > 
 > Nikita Danilov wrote (ao):
 > > new snapshot has been released. It is mainly bug-fixing release.
 > > 
 > > Take a look at the READ.ME for the list of known problems.
 > 
 > There are two LATEST_IS files in the snapshots dir.

Thanks, fixed.

 > 
 > Btw, can you please make a snapshot against the -mm tree? I think that
 > would help to get it included in that tree.

Well, making two snapshots is kind of "double trouble", because both has
to be tested and bug reports for them have to be handled. What we can
do, on the other hand, is to make a decision to switch to the -mm series
completely. But this is for Hans to decide.

Are you actually having any problems with applying/running snapshot on
top of -mm?

 > 
 > Thanks for this release!
 > 
 > With kind regards, Sander

Nikita.

 > 

Re: Last reiser4 snapshot is at: http://www.namesys.com/snapshots/2004.02.06/

[Sander]

Nikita Danilov wrote (ao):
> Sander writes:
>  > Btw, can you please make a snapshot against the -mm tree? I think
>  > that would help to get it included in that tree.
> 
> Well, making two snapshots is kind of "double trouble", because both
> has to be tested and bug reports for them have to be handled. What we
> can do, on the other hand, is to make a decision to switch to the -mm
> series completely. But this is for Hans to decide.

IMVHO, that would be a good thing.

> Are you actually having any problems with applying/running snapshot on
> top of -mm?

Yes, but I haven't looked into them yet. This is on 2.6.2 with -mm1
applied:

 $ patch -p1 -s -i ../all.diff
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
2 out of 2 hunks ignored -- saving rejects to file fs/Makefile.rej
1 out of 1 hunk FAILED -- saving rejects to file arch/i386/kernel/entry.S.rej
1 out of 2 hunks FAILED -- saving rejects to file include/asm-i386/unistd.h.rej
3 out of 3 hunks FAILED -- saving rejects to file ./include/asm-i386/thread_info.h.rej
1 out of 1 hunk FAILED -- saving rejects to file ./arch/i386/kernel/init_task.c.rej

Thank you.

With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

mm vs. official for reiser4.

[Hans Reiser]

Until we have removed all bugs that we can hit with internal testing, we 
will produce snapshots for use with only one kernel branch.  I am 
guessing that more reiser4 testers will use Linus kernel than Morton's.  
Readers should correct me if I err.....


Nikita Danilov wrote:

>Sander writes:
> > Hi Nikita,
> > 
> > Nikita Danilov wrote (ao):
> > > new snapshot has been released. It is mainly bug-fixing release.
> > > 
> > > Take a look at the READ.ME for the list of known problems.
> > 
> > There are two LATEST_IS files in the snapshots dir.
>
>Thanks, fixed.
>
> > 
> > Btw, can you please make a snapshot against the -mm tree? I think that
> > would help to get it included in that tree.
>
>Well, making two snapshots is kind of "double trouble", because both has
>to be tested and bug reports for them have to be handled. What we can
>do, on the other hand, is to make a decision to switch to the -mm series
>completely. But this is for Hans to decide.
>
>Are you actually having any problems with applying/running snapshot on
>top of -mm?
>
> > 
> > Thanks for this release!
> > 
> > With kind regards, Sander
>
>Nikita.
>
> > 
>
>
>  
>

Re: mm vs. official for reiser4.

[Sander]

Hi Hans,

Hans Reiser wrote (ao):
> Until we have removed all bugs that we can hit with internal testing,
> we will produce snapshots for use with only one kernel branch. I am
> guessing that more reiser4 testers will use Linus kernel than
> Morton's. Readers should correct me if I err.....

Well, I use -mm exclusively. Not only because it is more moving than the
standard kernel (it even has some extra trees which are not in the
standard kernel), but also because Andrew will be the 2.6 maintainer
after Linus opens 2.7.

Also, your plans are to get Reiserfs4 into the -mm tree first, right?
Then IMHO it makes more sense to move the current snapshots to -mm now,
as people can test it and tell Andrew it works great. And then when it
gets included in -mm, people don't have to switch from standard kernel +
snapshot patch, to a (quite different from standard) -mm tree.

Also, because -mm and standard are so different, if people switch from
standard+snapshot to -mm, it might be hard to tell if a bug is because
of the different tree, of because of Reiserfs4.

But you are the chief of course :-)

With kind regards, Sander

-- 
Humilis IT Services and Solutions
http://www.humilis.net

stat-data problems with the 2004.02.06 snapshot

[Henning Westerholt]

Hello Nikita,

thank you for the updated snapshot!
I tried it with 2.6.2 and noticed the following problem on my system:

*** Output from /var/log/messages ***

Feb  7 15:51:50 sonne kernel: reiser4[strip(30695)]: delete_inode_common 
(fs/reiser4/plugin/object.c:1027)[vs-1434]:
Feb  7 15:51:50 sonne kernel: WARNING: nrpages 3
Feb  7 15:51:50 sonne kernel: Feb  7 15:51:50 sonne kernel: reiser4
[strip(30701)]: delete_inode_common (fs/reiser4/plugin/object.c:1027)
[vs-1434]:
Feb  7 15:51:50 sonne kernel: WARNING: nrpages 2
Feb  7 15:51:50 sonne kernel: Feb  7 15:51:51 sonne kernel: reiser4
[strip(30721)]: delete_inode_common (fs/reiser4/plugin/object.c:1027)
[vs-1434]:
Feb  7 15:51:51 sonne kernel: WARNING: nrpages 1
... 


*** Output from fsck.reiser4 ***
Reiser4 fs was detected on the /dev/hdd9.
Master super block (16):
magic:          ReIsEr4
blksize:        4096
format:         0x0 (format40)
uuid:           921a81ba-f1aa-47b8-846c-71af014be94d
label:          <none>

Format super block (17):
plugin:         format40
description:    Disk-format for reiser4, ver. 0.5.0
magic:          ReIsEr40FoRmAt
flushes:        0
mkfs id:        0x46a0ee0e
blocks:         2441872
free blocks:    1671323
root block:     75948
tail policy:    0x4 (smart)
next oid:       0x5f7b6
file count:     139258
tree height:    4
key policy:     LARGE
[...]
Error: Node (745146), item (12): StatData of the file 
[278ba:656e7669726f6e:278bb] has the wrong bytes (48445), Should be (49152). 
Plugin (stat40).
Error: Node (745159), item (4): StatData of the file 
[278bf:656e7669726f6e:278c0] has the wrong bytes (53438), Should be (57344). 
Plugin (stat40).
Error: Node (745174), item (4): StatData of the file 
[278c4:656e7669726f6e:278c5] has the wrong bytes (72103), Should be (73728). 
Plugin (stat40).
Error: Node (743705), item (9): StatData of the file 
[27637:656e7669726f6e:27638] has the wrong bytes (46229), Should be (49152). 
Plugin (stat40):
...

These problems occour on a fresh filesystem after six hours compiling.  
fsck.reiser4 seems to fix this, nice work. 


With kind regards,

Henning

Re: mm vs. official for reiser4.

[Craig Knox]

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

On Fri, 2004-02-06 at 17:38, Hans Reiser wrote:
> Until we have removed all bugs that we can hit with internal testing, we 
> will produce snapshots for use with only one kernel branch.  I am 
> guessing that more reiser4 testers will use Linus kernel than Morton's.  
> Readers should correct me if I err.....

I use the -mm branch and wanted to test reiser4 when I reinstalled my
workstation the other day but it couldn't get them to play together
nicely so am now back to using ext3.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: mm vs. official for reiser4.

[Vince]

Count another vote in favour of the -mm branch. My opinion is that most 
reiser4 testers will also be likely to run the most "bleeding-edge" 
kernel branch...

Hans Reiser wrote:
> Until we have removed all bugs that we can hit with internal testing, we 
> will produce snapshots for use with only one kernel branch.  I am 
> guessing that more reiser4 testers will use Linus kernel than Morton's.  
> Readers should correct me if I err.....
> 

Re: mm vs. official for reiser4.

[Clifford Beshers]

I prefer Hans' method.  Limiting variables is essential for productive 
testing and debugging.  Get a stable FS with one kernel, make sure you 
understand all the issues, then deal with forks.

Vince wrote:

> Count another vote in favour of the -mm branch. My opinion is that 
> most reiser4 testers will also be likely to run the most 
> "bleeding-edge" kernel branch...
>
> Hans Reiser wrote:
>
>> Until we have removed all bugs that we can hit with internal testing, 
>> we will produce snapshots for use with only one kernel branch.  I am 
>> guessing that more reiser4 testers will use Linus kernel than 
>> Morton's.  Readers should correct me if I err.....
>>
>

Re: mm vs. official for reiser4.

[David Masover]

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

Not me.  I do this scientifically -- if something breaks, I want to know
it's reiser4, and not -mm.  But I know nothing about kernel politics, so
I can't say what you should do, only that I am not "bleeding-edge" about
most things.

Vince wrote:
| Count another vote in favour of the -mm branch. My opinion is that most
| reiser4 testers will also be likely to run the most "bleeding-edge"
| kernel branch...
|
| Hans Reiser wrote:
|
|> Until we have removed all bugs that we can hit with internal testing,
|> we will produce snapshots for use with only one kernel branch.  I am
|> guessing that more reiser4 testers will use Linus kernel than
|> Morton's.  Readers should correct me if I err.....
|>
|

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

iQIVAwUBQCgkbHgHNmZLgCUhAQImwRAAiJV7pr+fF9z1aDEjkmIIe+aKnXaQA/kr
WM0xtOBhXZk8Tk3mBVHuwEhsS9uf/SQ8/cx9CAnyLyNLZT4cUPKTh0KuMsGq5+CO
5pyIpfriauwEMA0LyYkmg14f8+pIrzQjCTH6ESL2uh08w+CKBuxyJPIOlt4TIYFs
Y9pdV2RyVpC8H0zDIgODN/MTA5GjuPz2WpTqrhajB6bwcMLUsnrncRRLRklVqC6J
HWJtcwrAZoUrwlRBj/DpZim/b275tN0AxD8OKa9QN+sEpqC7XCa8pXqFu3p5jvFr
dwOanSnPMfHqGOhpzNCK4XKXorJ1YzVgNywywp4OCocql/zJHtGxEO+HKX7AFxwe
0L7fzcRe4qQHrBSbMakXrA5h/txbcdD0+0hpy52feQ1A0YdffClzMsXQVvR19LQp
lgw9R7Cif9C5PN1pCMAZjs2FJgjSncJbq96wxg+dMfOxUualdqORML198q1HT3pV
RW2OfVTkJewuwuT52ZvU/2bSkmhQ43hzqWgpta4C3zmHlUzUoFxpwAEaTkTE1yFs
Vb3KiCN3MKDxvKwef1uj8w7alf3OxurqiXzFqHPViEA6Y+0IJbRNopl7BK+eeo9L
91ZS8WQKkkLWyLMH+u4I+Cyg89nFME6oLF6uELLvcEGBh0ROL5n6bFaHr7Qwym7x
GPYGcPBt22M=
=ucqy
-----END PGP SIGNATURE-----