Full of surprises - A reiser4 story from userland

Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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


Hello all,

I just wanted to tell along a bit about my recent experiences with
reiserfs. I have been using reiser3.[56] without any glitch for more
than five years and when I got a new notebook last year, I decided to
give reiser4 a try. There even was a handy kernel patch package
available in debian! How nice. A few bencharks proved my choice was
right. Over the last 12 months I was very happy with it - no sign of a
problem and pretty fast operation on 2.6.10 and 11.

A few days ago I decided to upgrade to 2.6.13 because I need it for
development at work. Having heard about the discussions around reiser4
kernel integration I supposed it should be quite stable now and that it
may even have improved some more. I also expected it to be readily
available as a kernel patch for everyone to try.

There was my first surprise: It was not! I spent quite some time
searching around and finally found that seemingly the only way to get
reiser4 for the latest kernel were a dozen and a half reiser4* patches
from mm. Their proper sequence of application also is up to the
technically interested user.
Why you request a software to be integrated into Linux while you dont
even provide an official patch download for the very kernel version you
want it in, is beyond my comprehension.

Well, since I needed 2.6.13 and my root partition already was reiser4 I
had to take things like they were. I spent another hour applying those
patches and getting around some minor problems doing so. Finally, there
was my shiny new 2.6.13 with reiser4.

But alas, the next surprise was not far away. Trying to suspend my
notebook now resulted in some reiser4 kernel processes going postal:

  PID USER      PR   SHR S  %CPU  %MEM    TIME+   COMMAND
  984 root      25     0 R  25.3   0.0   0:23.62  ktxnmgrd:dm-0:t
 3246 root      25     0 R  24.3   0.0   0:23.54  ktxnmgrd:hda4:t
  985 root      25     0 R  23.3   0.0   0:23.61  ent:dm-0.
 3247 root      25     0 S  23.3   0.0   0:23.60  ent:hda4.

The load went up to 8 and my computer became the most expensive heater
on the block. Reboot unavoidable. Maybe reiser4 had not improved that
much. A short check on the net just popped a few posts about recent
reiser4 being "a turkey" and that someone should put up a warning
somewhere (DAMN YES YOU SHOULD) but no solution.
I decided to go back to 2.6.11 before any more bad things happen.

Third surprise: they had already happened. 2.6.11 refused to boot the
root partition, claiming that there were an inconsistency in the FS.

Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd
(fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]:
Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42

I know the disk is ok and I had not had a crash of any sort (the freaked
out kernel from above seemed to shut down properly at least). So I
probed this a bit further:

trying 2.6.13 reiser4:   booting without a warning.
trying 2.6.11 again:     error, error, no go
trying 2.6.13 once more: booting nicely
trying 2.6.11 finally:   error again.

Okay, I'd call this another surprise. I just did not know whether there
actually was a problem or not! So I decided to give fsck a shot (on
2.6.11 - I had somewhat lost my belief in recent reiser4 code).
I just ran in with --check, because the man page said that this would be
read-only. It found this:

FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
valid SD
plugin set extention: wrong pset member count detected (12).
FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
valid stat data.
FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found.
FSCK: Node (2196341): the node is broken. Pointed from the node
(2196340), item (0), unit (0). The whole subtree is skipped.

Of course, as a user, I don't have the slightest idea what this means.
"The whole subtree is skipped" sounded worryingly lossy, however.
At the end of the run, fsck told me I had to rerun it with --build-fs.
Now that sounded pretty heavy. I still have some real work to do and I
already had lost several working hours to this and was not very willing
to do so right now.
So I decided to take advantage of the now proven fact that
REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it
another go for today (I made a backup the other day anyway), save my
work on NFS and let the --build-fs thing run tonight after work.

There was my fourth surprise: This fsck thing had LIED to me; it was not
read-only. It may have checked the fs read-only but it must have
treacherously flipped some "error" bit somewhere on disk because now
even 2.6.13 reiser4 refused to boot the partition properly:

Warning, mounting filesystem with fatal errors, forcing read-only mount
(followed by the error from above)

So much for --check being just a check. I grabbed a book and lost about
two more precious working hours running the --build-fs thing.

At this point I admittedly was >slightly< upset. No, wait. I was pissed.

After the rebuild had finally finished, I dropped my book and rebooted
into 2.6.11. But hey ho, surprises had not ended yet: The root partition
still booted read-only telling me it had fatal errors. Obviously that
switch flipped by the "read-only" check had not been flipped back during
the "read-write" restoration. So I probably have to remount,rw now after
every reboot.
But at least I can suspend again without my system going nuts.

The bottom line: obviously after twelve months without problems, some
higher entity has decided I am up for a busy day. Apart from the funny
"fatal error" thing my adventure ended where it had begun: I still need
2.6.13 and a working reiser4.
The version in mm obviously is seriously flawed and - from what I found
- may even cause file system corruption.

Probably the biggest surprise of all for me was that the people of
namesys put up such a pile of bugs right at the very moment they want
their stuff in the kernel tree. Anyone who is going the lengths to try
their code (maybe to evaluate whether it is actually worth incorporation
in the kernel) will be up for a not-so-nice surprise. And I did not see
a warning anywhere on namesys.com as well!

Now, would someone please tell me where I can find a reiser4 patch that
works as stable and surprise-free as your code back then in the old ages
of 2004 and that can be applied to 2.6.13? 
Please? Or would I have been better off using XFS from the beginning? 

Congratulations to all who read the whole story.

Thanks to everyone who will answer any of my questions.

best regards,
		Fionn

P.S.: How do I switch back that annoying "corruption bit"?
      Run another "read-only" check?
-- 
 Taking away civil rights to protect a free democracy is like taking off
 the tires of a car to protect it from flats.                       (FB)


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

Re: Full of surprises - A reiser4 story from userland

[Domenico Andreoli]

On Wed, Sep 28, 2005 at 03:40:12PM +0200, Fionn Behrens wrote:
> 
> Hello all,

hi,

> Now, would someone please tell me where I can find a reiser4 patch that
> works as stable and surprise-free as your code back then in the old ages
> of 2004 and that can be applied to 2.6.13? 

i'd be interested in such patch too, so that i can update the debian
package.

> Please? Or would I have been better off using XFS from the beginning? 

oh no.. why xfs jumps on my neck every time reiser4 has some problem?

regards
domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://people.debian.org/~cavok/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: Full of surprises - A reiser4 story from userland

[Clemens Eisserer]

> > Please? Or would I have been better off using XFS from the beginning?
Maybe this wouldn't be such a bad idea - since it would avoid such
unfriendly posts to the mailing list. Since YOU WANT help, you should
behave like its ment to be not always throughing arround how stupid
this and that is.
Lately there have been a lot changes suggested by kernel-developers to
get reiser4 into the mainline kernel, so that's why it not as stable
as it was.

Furthermore maybe this is the reason why there's no such patch, have
you thought this way round. Maybe only testers should use the current
version?

Man you get the best Linux-FS out there for free (I bet you did not
contribute) and all you do is nerving arround.

lg Clemens

ps: sorry for flaming, seems my emotions overheated...

Re: Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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

On Mi, 2005-09-28 at 16:51 +0200, Clemens Eisserer wrote:

> Man you get the best Linux-FS out there for free (I bet you did not
> contribute) and all you do is nerving arround.

Sorry if you see it this way. I actually took some time and effort to
write up a post that is at least mildly entertaining and tries to offer
understandable background on my emotions instead of simply posting an
"It dont werk! You suck!" ten-liner. At least I thought I did.

> ps: sorry for flaming, seems my emotions overheated...

Well, then you should have understood my post better than you pretend.

br,
	Fionn
-- 
"There ought to be limits to freedom!"
  *** US presidential candidate Gov. George W. Bush, press
      conference at the Texas State House, May 21, 1999


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

Re: Full of surprises - A reiser4 story from userland

[Vitaly Fertman]

On Wednesday 28 September 2005 17:40, Fionn Behrens wrote:
> 
> Hello all,

Hello
 
> I just wanted to tell along a bit about my recent experiences with
> reiserfs. I have been using reiser3.[56] without any glitch for more
> than five years and when I got a new notebook last year, I decided to
> give reiser4 a try. There even was a handy kernel patch package
> available in debian! How nice. A few bencharks proved my choice was
> right. Over the last 12 months I was very happy with it - no sign of a
> problem and pretty fast operation on 2.6.10 and 11.
> 
> A few days ago I decided to upgrade to 2.6.13 because I need it for
> development at work. Having heard about the discussions around reiser4
> kernel integration I supposed it should be quite stable now and that it
> may even have improved some more. I also expected it to be readily
> available as a kernel patch for everyone to try.
> 
> There was my first surprise: It was not! I spent quite some time
> searching around and finally found that seemingly the only way to get
> reiser4 for the latest kernel were a dozen and a half reiser4* patches
> from mm. Their proper sequence of application also is up to the
> technically interested user.
> Why you request a software to be integrated into Linux while you dont
> even provide an official patch download for the very kernel version you
> want it in, is beyond my comprehension.
> 
> Well, since I needed 2.6.13 and my root partition already was reiser4 I
> had to take things like they were. I spent another hour applying those
> patches and getting around some minor problems doing so. Finally, there
> was my shiny new 2.6.13 with reiser4.
> 
> But alas, the next surprise was not far away. Trying to suspend my
> notebook now resulted in some reiser4 kernel processes going postal:
> 
>   PID USER      PR   SHR S  %CPU  %MEM    TIME+   COMMAND
>   984 root      25     0 R  25.3   0.0   0:23.62  ktxnmgrd:dm-0:t
>  3246 root      25     0 R  24.3   0.0   0:23.54  ktxnmgrd:hda4:t
>   985 root      25     0 R  23.3   0.0   0:23.61  ent:dm-0.
>  3247 root      25     0 S  23.3   0.0   0:23.60  ent:hda4.
> 
> The load went up to 8 and my computer became the most expensive heater
> on the block. Reboot unavoidable. Maybe reiser4 had not improved that
> much. A short check on the net just popped a few posts about recent
> reiser4 being "a turkey" and that someone should put up a warning
> somewhere (DAMN YES YOU SHOULD) but no solution.
> I decided to go back to 2.6.11 before any more bad things happen.
> 
> Third surprise: they had already happened. 2.6.11 refused to boot the
> root partition, claiming that there were an inconsistency in the FS.

the disk format got new parameters and old kernels cannot understand it right.

> Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
> Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd
> (fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]:
> Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42
> 
> I know the disk is ok and I had not had a crash of any sort (the freaked
> out kernel from above seemed to shut down properly at least). So I
> probed this a bit further:
> 
> trying 2.6.13 reiser4:   booting without a warning.
> trying 2.6.11 again:     error, error, no go
> trying 2.6.13 once more: booting nicely
> trying 2.6.11 finally:   error again.
> 
> Okay, I'd call this another surprise. I just did not know whether there
> actually was a problem or not! So I decided to give fsck a shot (on

which fsck version?

> 2.6.11 - I had somewhat lost my belief in recent reiser4 code).
> I just ran in with --check, because the man page said that this would be
> read-only. 

it says:
"
--check
the default action checks the consistency and reports, but does not 
repair any corruption that it finds. This option may be used on a 
read-only file system mount.
"

it does not mean 100% read-only check. 

> It found this: 
> 
> FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
> valid SD
> plugin set extention: wrong pset member count detected (12).
> FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
> valid stat data.
> FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found.
> FSCK: Node (2196341): the node is broken. Pointed from the node
> (2196340), item (0), unit (0). The whole subtree is skipped.
> 
> Of course, as a user, I don't have the slightest idea what this means.
> "The whole subtree is skipped" sounded worryingly lossy, however.
> At the end of the run, fsck told me I had to rerun it with --build-fs.
> Now that sounded pretty heavy. I still have some real work to do and I
> already had lost several working hours to this and was not very willing
> to do so right now.
> So I decided to take advantage of the now proven fact that
> REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it
> another go for today (I made a backup the other day anyway), save my
> work on NFS and let the --build-fs thing run tonight after work.
> 
> There was my fourth surprise: This fsck thing had LIED to me; it was not
> read-only. 

why do you think --build-fs is read-only? 

> It may have checked the fs read-only but it must have 
> treacherously flipped some "error" bit somewhere on disk because now
> even 2.6.13 reiser4 refused to boot the partition properly:
> 
> Warning, mounting filesystem with fatal errors, forcing read-only mount
> (followed by the error from above)

do you see anything relevant in the syslog?

> So much for --check being just a check. I grabbed a book and lost about
> two more precious working hours running the --build-fs thing.
> 
> At this point I admittedly was >slightly< upset. No, wait. I was pissed.
> 
> After the rebuild had finally finished, I dropped my book and rebooted
> into 2.6.11. But hey ho, surprises had not ended yet: The root partition
> still booted read-only telling me it had fatal errors. 

you need to clarify what reiser4progs version you are running.
1.0.5 fixes the fs to the letest format, which is needed for 2.6.13.
1.0.3 to the 2.6.10's one. 

> Obviously that 
> switch flipped by the "read-only" check had not been flipped back during
> the "read-write" restoration. So I probably have to remount,rw now after
> every reboot.
> But at least I can suspend again without my system going nuts.
> 
> The bottom line: obviously after twelve months without problems, some
> higher entity has decided I am up for a busy day. Apart from the funny
> "fatal error" thing my adventure ended where it had begun: I still need
> 2.6.13 and a working reiser4.
> The version in mm obviously is seriously flawed and - from what I found
> - may even cause file system corruption.
> 
> Probably the biggest surprise of all for me was that the people of
> namesys put up such a pile of bugs right at the very moment they want
> their stuff in the kernel tree. Anyone who is going the lengths to try
> their code (maybe to evaluate whether it is actually worth incorporation
> in the kernel) will be up for a not-so-nice surprise. And I did not see
> a warning anywhere on namesys.com as well!
> 
> Now, would someone please tell me where I can find a reiser4 patch that
> works as stable and surprise-free as your code back then in the old ages
> of 2004 and that can be applied to 2.6.13? 
> Please? Or would I have been better off using XFS from the beginning? 
> 
> Congratulations to all who read the whole story.
> 
> Thanks to everyone who will answer any of my questions.
> 
> best regards,
> 		Fionn
> 
> P.S.: How do I switch back that annoying "corruption bit"?
>       Run another "read-only" check?

-- 
Vitaly

Re: Full of surprises - A reiser4 story from userland

[Islam Amer]

On 9/28/05, Vitaly Fertman <vitaly@namesys.com> wrote:
> On Wednesday 28 September 2005 17:40, Fionn Behrens wrote:
> >
> > Hello all,
>
> Hello
>
> > I just wanted to tell along a bit about my recent experiences with
> > reiserfs. I have been using reiser3.[56] without any glitch for more
> > than five years and when I got a new notebook last year, I decided to
> > give reiser4 a try. There even was a handy kernel patch package
> > available in debian! How nice. A few bencharks proved my choice was
> > right. Over the last 12 months I was very happy with it - no sign of a
> > problem and pretty fast operation on 2.6.10 and 11.
> >
> > A few days ago I decided to upgrade to 2.6.13 because I need it for
> > development at work. Having heard about the discussions around reiser4
> > kernel integration I supposed it should be quite stable now and that it
> > may even have improved some more. I also expected it to be readily
> > available as a kernel patch for everyone to try.
> >
> > There was my first surprise: It was not! I spent quite some time
> > searching around and finally found that seemingly the only way to get
> > reiser4 for the latest kernel were a dozen and a half reiser4* patches
> > from mm. Their proper sequence of application also is up to the
> > technically interested user.
> > Why you request a software to be integrated into Linux while you dont
> > even provide an official patch download for the very kernel version you
> > want it in, is beyond my comprehension.
> >
> > Well, since I needed 2.6.13 and my root partition already was reiser4 I
> > had to take things like they were. I spent another hour applying those
> > patches and getting around some minor problems doing so. Finally, there
> > was my shiny new 2.6.13 with reiser4.
> >
> > But alas, the next surprise was not far away. Trying to suspend my
> > notebook now resulted in some reiser4 kernel processes going postal:
> >
> >   PID USER      PR   SHR S  %CPU  %MEM    TIME+   COMMAND
> >   984 root      25     0 R  25.3   0.0   0:23.62  ktxnmgrd:dm-0:t
> >  3246 root      25     0 R  24.3   0.0   0:23.54  ktxnmgrd:hda4:t
> >   985 root      25     0 R  23.3   0.0   0:23.61  ent:dm-0.
> >  3247 root      25     0 S  23.3   0.0   0:23.60  ent:hda4.
> >
> > The load went up to 8 and my computer became the most expensive heater
> > on the block. Reboot unavoidable. Maybe reiser4 had not improved that
> > much. A short check on the net just popped a few posts about recent
> > reiser4 being "a turkey" and that someone should put up a warning
> > somewhere (DAMN YES YOU SHOULD) but no solution.
> > I decided to go back to 2.6.11 before any more bad things happen.
> >
> > Third surprise: they had already happened. 2.6.11 refused to boot the
> > root partition, claiming that there were an inconsistency in the FS.
>
> the disk format got new parameters and old kernels cannot understand it right.
>
> > Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
> > Sep 28 08:44:20 rtfm kernel: reiser4[mount(840)]: init_inode_static_sd
> > (fs/reiser4/plugin/item/static_stat.c:283)[nikita-631]:
> > Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42
> >
> > I know the disk is ok and I had not had a crash of any sort (the freaked
> > out kernel from above seemed to shut down properly at least). So I
> > probed this a bit further:
> >
> > trying 2.6.13 reiser4:   booting without a warning.
> > trying 2.6.11 again:     error, error, no go
> > trying 2.6.13 once more: booting nicely
> > trying 2.6.11 finally:   error again.
> >
> > Okay, I'd call this another surprise. I just did not know whether there
> > actually was a problem or not! So I decided to give fsck a shot (on
>
> which fsck version?
>
> > 2.6.11 - I had somewhat lost my belief in recent reiser4 code).
> > I just ran in with --check, because the man page said that this would be
> > read-only.
>
> it says:
> "
> --check
> the default action checks the consistency and reports, but does not
> repair any corruption that it finds. This option may be used on a
> read-only file system mount.
> "
>
> it does not mean 100% read-only check.
>
> > It found this:
> >
> > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
> > valid SD
> > plugin set extention: wrong pset member count detected (12).
> > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: does not look like a
> > valid stat data.
> > FSCK: Node (2196341), item (0), [29:1(SD):0:2a:0]: broken item found.
> > FSCK: Node (2196341): the node is broken. Pointed from the node
> > (2196340), item (0), unit (0). The whole subtree is skipped.
> >
> > Of course, as a user, I don't have the slightest idea what this means.
> > "The whole subtree is skipped" sounded worryingly lossy, however.
> > At the end of the run, fsck told me I had to rerun it with --build-fs.
> > Now that sounded pretty heavy. I still have some real work to do and I
> > already had lost several working hours to this and was not very willing
> > to do so right now.
> > So I decided to take advantage of the now proven fact that
> > REISER4-2.6.13 DOES NOT RECOGNIZE ITS SELF-MADE DAMAGE and give it
> > another go for today (I made a backup the other day anyway), save my
> > work on NFS and let the --build-fs thing run tonight after work.
> >
> > There was my fourth surprise: This fsck thing had LIED to me; it was not
> > read-only.
>
> why do you think --build-fs is read-only?
>
> > It may have checked the fs read-only but it must have
> > treacherously flipped some "error" bit somewhere on disk because now
> > even 2.6.13 reiser4 refused to boot the partition properly:
> >
> > Warning, mounting filesystem with fatal errors, forcing read-only mount
> > (followed by the error from above)
>
> do you see anything relevant in the syslog?
>
> > So much for --check being just a check. I grabbed a book and lost about
> > two more precious working hours running the --build-fs thing.
> >
> > At this point I admittedly was >slightly< upset. No, wait. I was pissed.
> >
> > After the rebuild had finally finished, I dropped my book and rebooted
> > into 2.6.11. But hey ho, surprises had not ended yet: The root partition
> > still booted read-only telling me it had fatal errors.
>
> you need to clarify what reiser4progs version you are running.
> 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13.
> 1.0.3 to the 2.6.10's one.
>
> > Obviously that
> > switch flipped by the "read-only" check had not been flipped back during
> > the "read-write" restoration. So I probably have to remount,rw now after
> > every reboot.
> > But at least I can suspend again without my system going nuts.
> >
> > The bottom line: obviously after twelve months without problems, some
> > higher entity has decided I am up for a busy day. Apart from the funny
> > "fatal error" thing my adventure ended where it had begun: I still need
> > 2.6.13 and a working reiser4.
> > The version in mm obviously is seriously flawed and - from what I found
> > - may even cause file system corruption.
> >
> > Probably the biggest surprise of all for me was that the people of
> > namesys put up such a pile of bugs right at the very moment they want
> > their stuff in the kernel tree. Anyone who is going the lengths to try
> > their code (maybe to evaluate whether it is actually worth incorporation
> > in the kernel) will be up for a not-so-nice surprise. And I did not see
> > a warning anywhere on namesys.com as well!
> >
> > Now, would someone please tell me where I can find a reiser4 patch that
> > works as stable and surprise-free as your code back then in the old ages
> > of 2004 and that can be applied to 2.6.13?
> > Please? Or would I have been better off using XFS from the beginning?
> >
> > Congratulations to all who read the whole story.
> >
> > Thanks to everyone who will answer any of my questions.
> >
> > best regards,
> >               Fionn
> >
> > P.S.: How do I switch back that annoying "corruption bit"?
> >       Run another "read-only" check?
>
> --
> Vitaly
>

I don't like to turn LKML into another battleground, but from one user
to another I have to answer this.

*You know reiser4 is development code , this is why it isn't included
in vanilla ( yet ) in the first place.

*reiser4 is included in mm and the separate patches from the
broken-out package should be applied in the order listed in the
included series file ( usually using quilt ).

*I too faced problems when I upgraded to 2.6.13-mm because of the
change in the filesystem format. However everything returned to normal
when I upgraded my progsreiserfs and repatched grub with the latest
patch.

*reiser4 is sometimes victimized due to bugs in the -mm releases. For
example I am having problems with a 100% cpu usage of a process called
" ent:hda7! " cured only by a reboot. The problem has eased a little
when I replaced the " per-task-predictive-write-throttling". However I
think the problem still exists.

*reiser4 is in a state of flux due to the code changes being made in
preparation for the review leading to ( hopefully ) its inclusion in
the kernel.

I hope I cleared some of the problems you complained of , and I hope I
didn't step on someones toes or make someone upset. If I did , I
apologize in advance. Thank you.

Re: Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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

On Mi, 2005-09-28 at 17:51 +0300, Islam Amer wrote:

[FQ deleted]

> I don't like to turn LKML into another battleground,

You mean because of fullquote-flames? ;-)
Seriously, I did not post this to lkml (although I was tempted).

> but from one user to another I have to answer this.
> 
> *You know reiser4 is development code , this is why it isn't included
> in vanilla ( yet ) in the first place.
> 
> *reiser4 is included in mm and the separate patches from the
> broken-out package should be applied in the order listed in the
> included series file ( usually using quilt ).

Sorry, I never used mm so far. Didn't know that. My fault.

> *reiser4 is sometimes victimized due to bugs in the -mm releases. For
> example I am having problems with a 100% cpu usage of a process called
> " ent:hda7! " cured only by a reboot. The problem has eased a little
> when I replaced the " per-task-predictive-write-throttling". However I
> think the problem still exists.

Sounds very much like what I experienced. As I don't have any other mm
patch installed the code obviously could not be victimized that way.
It is just broken.

> *reiser4 is in a state of flux due to the code changes being made in
> preparation for the review leading to ( hopefully ) its inclusion in
> the kernel.

I'd just wish I had found a sentence like this and a warning on
namesys.com when I began looking for a patch. Everything would have been
so much easier.

> I hope I cleared some of the problems you complained of , and I hope I
> didn't step on someones toes or make someone upset.

Of course not. Actually I might have to apologize:

Because of my good experiences with ReiserFS in the past I had high
expectations. As you correctly and rightfully stated, reiser4 is
development code and that probably means I should not rely on anything.

I just snapped in disappointment and if anyone else thinks I overreacted
then I apologize to you all for any offense taken.
Next time, I will be more careful.

best regards,
		Fionn
-- 
 Taking away civil rights to protect a free democracy is like taking off
 the tires of a car to protect it from flats. 

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

Re: Full of surprises - A reiser4 story from userland

[Hans Reiser]

Fionn Behrens wrote:

>
>
>Because of my good experiences with ReiserFS in the past I had high
>expectations. As you correctly and rightfully stated, reiser4 is
>development code and that probably means I should not rely on anything.
>  
>
Well, it had gone stable, sorry we let it destable.....

Hans

Re: Full of surprises - A reiser4 story from userland

[Hans Reiser]

I apologize that the latest reiser4 with the cleanups requested by
Hellwig is more than a bit of a turkey (due to bugs in our cleanups). 
We just now sent some patches which will improve things, but I don't yet
have confidence in the code, and will not until we go for two weeks with
no reports of problems.  It may also be that the new to -mm write
throttling patch is causing us problems, we are still investigating.

Hans

Re: Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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

On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote:

> > 2.6.11 refused to boot the
> > root partition, claiming that there were an inconsistency in the FS.
> 
> the disk format got new parameters and old kernels cannot understand it right.

Ah, I see. So maybe it would be a good idea if the new fs version would
put up a big fat warning to syslog when it detects a partition written
by a previous version, telling the user that he is about to break
compatibility to his older version (and that the must upgrade userland
tools, too!)

> > Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
> > Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42

> which fsck version?

1.0.4

> > the man page said that this would be read-only. 
> 
> it says:
> " --check
> the default action checks the consistency and reports, but does not 
> repair any corruption that it finds. This option may be used on a 
> read-only file system mount.
> "
> it does not mean 100% read-only check. 

Okay, you sound a bit like a lawyer, but: you right me wrong.

> > There was my fourth surprise: This fsck thing had LIED to me; it was not
> > read-only. 
> 
> why do you think --build-fs is read-only? 

Had not gone --build-fs yet. This was still about --check.

> > It may have checked the fs read-only but it must have 
> > treacherously flipped some "error" bit somewhere on disk

> > Warning, mounting filesystem with fatal errors, forcing read-only mount
> > (followed by the error from above)
> 
> do you see anything relevant in the syslog?

That line was in the syslog.

> > So much for --check being just a check. I grabbed a book and lost about
> > two more precious working hours running the --build-fs thing.

> you need to clarify what reiser4progs version you are running.
> 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13.
> 1.0.3 to the 2.6.10's one. 

1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to
1.0.5 or would that not do harm anyway?

thanks for answering!

kind regards,
		Fionn
-- 
I believe we have been called by history to lead the world.
                                                 G.W. Bush, 2002-03-01


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

Re: Full of surprises - A reiser4 story from userland

[David Masover]

Fionn Behrens wrote:
> On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote:
> 
> 
>>>2.6.11 refused to boot the
>>>root partition, claiming that there were an inconsistency in the FS.
>>
>>the disk format got new parameters and old kernels cannot understand it right.
> 
> 
> Ah, I see. So maybe it would be a good idea if the new fs version would
> put up a big fat warning to syslog when it detects a partition written
> by a previous version, telling the user that he is about to break
> compatibility to his older version (and that the must upgrade userland
> tools, too!)

Yes, it would be nice, and I wish it'd been done that way.  I'm hoping
it will be once it's in the kernel.  I liked how I didn't have to do
anything for the upgrade to happen, but I'd probably like it more if
this was something you had to do with a userland tool or a specific
kernel boot/mount option.

> 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to
> 1.0.5 or would that not do harm anyway?

Not sure.  I got 2.6.13 to work without much trouble, but I wasn't using
the full MM patch, just the reiser4-specific parts.

Re: Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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

On Mi, 2005-09-28 at 10:57 -0500, David Masover wrote:

> I got 2.6.13 to work without much trouble, but I wasn't using
> the full MM patch, just the reiser4-specific parts.

I did exactly the same and was less lucky. 

br,
	Fionn
-- 
80% of the Republicans I meet are just Democrats who
don't know what's going on.                  *** Robert Kennedy Jr.

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

Re: Full of surprises - A reiser4 story from userland

[Islam Amer]

Sorry about the full quotes, I just hit reply all in gmail and type in
my email. I thought this was how the mailing list knows which thread
to attatch my email to. Pardon my ignorance.

Yes reiser4 was very solid but now it became a little shaky.

little off topic:
BTW, Previously I had amazing performance with anticipatory
IO-scheduler ( even more so with genetic anticipatory ) any comments
on this io-scheduler business, as it stirred up some commotion before.
Is the performance boost an illusion or is it not.

iosched (was Re: Full of surprises - A reiser4 story from userland)

[Valdis.Kletnieks]

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

On Wed, 28 Sep 2005 22:13:52 +0300, Islam Amer said:

> BTW, Previously I had amazing performance with anticipatory
> IO-scheduler ( even more so with genetic anticipatory ) any comments
> on this io-scheduler business, as it stirred up some commotion before.
> Is the performance boost an illusion or is it not.

The performance boost for any of the provided iosched schemes can be
positive, negative, imaginary, or complex(*), depending on the actual workload of
the system, and what reference patterns it generates.

There's 4 in-tree schedulers precisely because each of them has a clear-cut
advantage for some statistic (be it throughput, or latency, or CPU overhead, or
whatever) for some identified workload type.

(*) I suspect that (benchmarks being benchmarks) the chance that the boost
be totally real, with no imaginary component, is very slim.  And everybody
knows that most benchmark results are complex to interpret.. :)

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Islam Amer]

> The performance boost for any of the provided iosched schemes can be
> positive, negative, imaginary, or complex(*), depending on the actual workload of
> the system, and what reference patterns it generates.
>
I assumed published benchmarks are conducted under strictly controlled
conditions.

> (*) I suspect that (benchmarks being benchmarks) the chance that the boost
> be totally real, with no imaginary component, is very slim.  And everybody
> knows that most benchmark results are complex to interpret.. :)

Then this scheduler is doing a very good job at creating an illusion
of enhanced performance.
Thanks for the reply :)

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Hans Reiser]

Islam Amer wrote:

>>The performance boost for any of the provided iosched schemes can be
>>positive, negative, imaginary, or complex(*), depending on the actual workload of
>>the system, and what reference patterns it generates.
>>
>>    
>>
>I assumed published benchmarks are conducted under strictly controlled
>conditions.
>  
>
The thing to do with benchmarks is to ask your friends and mailing lists
if the benchmarks seem accurate to them based on their usage experience.

The latest reiser4 has performance problems due to bugs added, but prior
to it there seemed to be agreement on our mailing list that experiences
matched our benchmarks.  Am I right?

Hans

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Hans Reiser]

 Check out the latest cfq in the latest kernel, it is much better than
the others for most applications.  Anticipatory used to be the best, but
cfq-3 is better now.

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Islam Amer]

On 9/28/05, Hans Reiser <reiser@namesys.com> wrote:
>  Check out the latest cfq in the latest kernel, it is much better than
> the others for most applications.  Anticipatory used to be the best, but
> cfq-3 is better now.
>
Yes I always had my eyes on the applicable parts of -ck patchset
becasue they showed good promise ( upto my limited understading ). I
just needed an educated opinion. Thanks.

And  I had to drop using the genetic-as because it oopsed with
reiserfs in some kernels.

Problem is lots of experimental patches in -mm series hurt throughput
and performance and reiser4 users have to suffer. Otherwise we have to
go through the slightly non-trivial procedure of patching the vanilla
kernel.

vs, can you port to 2.6.13 and put the port on our website as part of analyzing the latest patches added to the -mm series and their impact on reiser4 performance

[Hans Reiser]

;-)

Thanks,

Hans

Islam Amer wrote:

>On 9/28/05, Hans Reiser <reiser@namesys.com> wrote:
>  
>
>> Check out the latest cfq in the latest kernel, it is much better than
>>the others for most applications.  Anticipatory used to be the best, but
>>cfq-3 is better now.
>>
>>    
>>
>Yes I always had my eyes on the applicable parts of -ck patchset
>becasue they showed good promise ( upto my limited understading ). I
>just needed an educated opinion. Thanks.
>
>And  I had to drop using the genetic-as because it oopsed with
>reiserfs in some kernels.
>
>Problem is lots of experimental patches in -mm series hurt throughput
>and performance and reiser4 users have to suffer. Otherwise we have to
>go through the slightly non-trivial procedure of patching the vanilla
>kernel.
>
>
>  
>

Re: vs, can you port to 2.6.13 and put the port on our website as part of analyzing the latest patches added to the -mm series and their impact on reiser4 performance

[Vladimir V. Saveliev]

Hello

Hans Reiser wrote:
> ;-)
> 
> Thanks,
> 
> Hans
> 
> Islam Amer wrote:
> 
>>On 9/28/05, Hans Reiser <reiser@namesys.com> wrote:
>> 
>>
>>>Check out the latest cfq in the latest kernel, it is much better than
>>>the others for most applications.  Anticipatory used to be the best, but
>>>cfq-3 is better now.
>>>
>>>   
>>>
>>Yes I always had my eyes on the applicable parts of -ck patchset
>>becasue they showed good promise ( upto my limited understading ). I
>>just needed an educated opinion. Thanks.
>>
>>And  I had to drop using the genetic-as because it oopsed with
>>reiserfs in some kernels.
>>
>>Problem is lots of experimental patches in -mm series hurt throughput
>>and performance and reiser4 users have to suffer. Otherwise we have to
>>go through the slightly non-trivial procedure of patching the vanilla
>>kernel.
>>

reiser4 for 2.6.13 can be obtained at
ftp://ftp.namesys.com/pub/reiser4-for-2.6/2.6.13/

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[David Masover]

Islam Amer wrote:

> Problem is lots of experimental patches in -mm series hurt throughput
> and performance and reiser4 users have to suffer. Otherwise we have to
> go through the slightly non-trivial procedure of patching the vanilla
> kernel.

Non-trivial?  How's this:

for i in `egrep '^reiser4' ../broken-out/series`; do
	patch -p1 < ../broken-out/$1;
done

That won't always work, but it's certainly trivial.

Places it won't work:  patch names with spaces (won't happen), commented
patches (just generates weird errors), and a couple of kernels also need
the attached patch.  I don't remember which ones, but you get a compiler
error unless you've got it right.

It'll also fail (obviously) if anything's changed since I last checked.

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[michael chang]

On 9/28/05, David Masover <ninja@slaphack.com> wrote:
> Islam Amer wrote:
>
> > Problem is lots of experimental patches in -mm series hurt throughput
> > and performance and reiser4 users have to suffer. Otherwise we have to
> > go through the slightly non-trivial procedure of patching the vanilla
> > kernel.
>
> Non-trivial?  How's this:

I'm not sure, but I do believe he was referring to official vanilla
patch submission... although I could be wrong.

IIRC, don't vanilla and -mm have some somewhat substancial internal
differences that could require manual changes?  I could be wrong
though, I've never even looked at the diffs/patches for vanilla vs
-mm.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Islam Amer]

>
> IIRC, don't vanilla and -mm have some somewhat substancial internal
> differences that could require manual changes?  I could be wrong
> though, I've never even looked at the diffs/patches for vanilla vs
> -mm.
>
That's what I am pointing to. The patches might apply cleanly or have
a few FAILED hunks that can be fixed easily by hand. But what do I
know about the changes made to the vfs layer etc..
I could break something without knowing it.

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[David Masover]

Islam Amer wrote:
>>IIRC, don't vanilla and -mm have some somewhat substancial internal
>>differences that could require manual changes?  I could be wrong
>>though, I've never even looked at the diffs/patches for vanilla vs
>>-mm.
>>
> 
> That's what I am pointing to. The patches might apply cleanly or have
> a few FAILED hunks that can be fixed easily by hand. But what do I
> know about the changes made to the vfs layer etc..
> I could break something without knowing it.

Maybe I did, but I've had a relatively sane experience with it so far...

Yet, Namesys has put out a 2.6.13 patch, so I'll be switching to that 
next time I have a reason to compile.

I'm running two amd64 boxes and one Pentium 2 on Reiser4, and will soon 
be putting it on a Powerbook.

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Dan Oglesby]

David Masover wrote:

> Islam Amer wrote:
>
>>> IIRC, don't vanilla and -mm have some somewhat substancial internal
>>> differences that could require manual changes?  I could be wrong
>>> though, I've never even looked at the diffs/patches for vanilla vs
>>> -mm.
>>>
>>
>> That's what I am pointing to. The patches might apply cleanly or have
>> a few FAILED hunks that can be fixed easily by hand. But what do I
>> know about the changes made to the vfs layer etc..
>> I could break something without knowing it.
>
>
> Maybe I did, but I've had a relatively sane experience with it so far...
>
> Yet, Namesys has put out a 2.6.13 patch, so I'll be switching to that 
> next time I have a reason to compile.
>
> I'm running two amd64 boxes and one Pentium 2 on Reiser4, and will 
> soon be putting it on a Powerbook.
>
By this weekend I'll have a Gentoo 2005.1 install running on a Sun Ultra 
II workstation (dual processor, 64-bit).  I'll let you guys know how the 
2.6.13 patch goes.

--Dan

iosched (was Re: Full of surprises - A reiser4 story from userland)

[studdugie]

On 9/28/05, Hans Reiser <reiser@namesys.com> wrote:
>  Check out the latest cfq in the latest kernel, it is much better than
> the others for most applications.  Anticipatory used to be the best, but
> cfq-3 is better now.
>
When you say the best is that a general conclusion for both single
disks and RAID?

Re: iosched (was Re: Full of surprises - A reiser4 story from userland)

[Jonathan Briggs]

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

On Wed, 2005-09-28 at 17:33 -0400, studdugie wrote:
> On 9/28/05, Hans Reiser <reiser@namesys.com> wrote:
> >  Check out the latest cfq in the latest kernel, it is much better than
> > the others for most applications.  Anticipatory used to be the best, but
> > cfq-3 is better now.
> >
> When you say the best is that a general conclusion for both single
> disks and RAID?

I find (but no hard data to provide) that no-op or deadline seems to
work best when working with an intelligent RAID controller.  Just push
the queue to the controller and it'll sort out the best way to get
things.
-- 
Jonathan Briggs <jbriggs@esoft.com>
eSoft, Inc.

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

Re: Full of surprises - A reiser4 story from userland

[Vitaly Fertman]

On Wednesday 28 September 2005 19:28, Fionn Behrens wrote:
> On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote:
> 
> > > 2.6.11 refused to boot the
> > > root partition, claiming that there were an inconsistency in the FS.
> > 
> > the disk format got new parameters and old kernels cannot understand it right.
> 
> Ah, I see. So maybe it would be a good idea if the new fs version would
> put up a big fat warning to syslog when it detects a partition written
> by a previous version, telling the user that he is about to break
> compatibility to his older version (and that the must upgrade userland
> tools, too!)
> 
> > > Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
> > > Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42
> 
> > which fsck version?
> 
> 1.0.4
> 
> > > the man page said that this would be read-only. 
> > 
> > it says:
> > " --check
> > the default action checks the consistency and reports, but does not 
> > repair any corruption that it finds. This option may be used on a 
> > read-only file system mount.
> > "
> > it does not mean 100% read-only check. 
> 
> Okay, you sound a bit like a lawyer, but: you right me wrong.
> 
> > > There was my fourth surprise: This fsck thing had LIED to me; it was not
> > > read-only. 
> > 
> > why do you think --build-fs is read-only? 
> 
> Had not gone --build-fs yet. This was still about --check.
> 
> > > It may have checked the fs read-only but it must have 
> > > treacherously flipped some "error" bit somewhere on disk
> 
> > > Warning, mounting filesystem with fatal errors, forcing read-only mount
> > > (followed by the error from above)
> > 
> > do you see anything relevant in the syslog?
> 
> That line was in the syslog.

ok, the flag that fs contains errors is indeed cleared only with --check with
all reiser4progs untill 1.0.5, the later is able to do it with any options. Thus
another --check run would clear the flag.

However 'the error from above' that is 'WARNING: wrong pset member 
(11) for 42' is possible with the old kernel only.

remember that reiser4progs-1.0.4 supports both formats, in other words
having the format updated to the new one, you are able to use new kernel
only. If you want to move back to 2.6.10, you have to build-fs with 1.0.3
version or reiser4progs.

> > > So much for --check being just a check. I grabbed a book and lost about
> > > two more precious working hours running the --build-fs thing.
> 
> > you need to clarify what reiser4progs version you are running.
> > 1.0.5 fixes the fs to the letest format, which is needed for 2.6.13.
> > 1.0.3 to the 2.6.10's one. 
> 
> 1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to
> 1.0.5 or would that not do harm anyway?

1.0.5 is 1.0.4 + bugfixes.

> thanks for answering!
> 
> kind regards,
> 		Fionn

-- 
Vitaly

Re: Full of surprises - A reiser4 story from userland

[Fionn Behrens]

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

On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote:

> remember that reiser4progs-1.0.4 supports both formats, in other words
> having the format updated to the new one, you are able to use new
> kernelonly. If you want to move back to 2.6.10, you have to build-fs
> with 1.0.3 version or reiser4progs.

Do I get this right? I had reiser4progs 1.0.4 and it should already know
the new format? If what you say is right then fsck should have not
complained about an error in the first place AND I still should not be
able to boot with the old kernel any more after --build-fs. 
But it found an error. And I ran --build-fs with it. And now I am using
the old kernel again and it does NOT complain about errors any more.
(except for that flag we discussed already). 

Pardon me, I am confused.

best regards,
		Fionn
-- 
 "I feel like God wants me to run for President. I can't explain it, 
  but I sense my country is going to need me."  *** George W. Bush, 1999
   Quoted from the book "The Faith of George W. Bush" by Steve Mansfield
  

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

Re: Full of surprises - A reiser4 story from userland

[Vitaly Fertman]

On Wednesday 28 September 2005 21:57, Fionn Behrens wrote:
> On Mi, 2005-09-28 at 20:40 +0400, Vitaly Fertman wrote:
> 
> > remember that reiser4progs-1.0.4 supports both formats, in other words
> > having the format updated to the new one, you are able to use new
> > kernelonly. If you want to move back to 2.6.10, you have to build-fs
> > with 1.0.3 version or reiser4progs.
> 
> Do I get this right? I had reiser4progs 1.0.4 and it should already know
> the new format? If what you say is right then fsck should have not
> complained about an error in the first place AND I still should not be
> able to boot with the old kernel any more after --build-fs. 
> But it found an error. And I ran --build-fs with it. And now I am using
> the old kernel again and it does NOT complain about errors any more.
> (except for that flag we discussed already). 
> 
> Pardon me, I am confused.

hm, before writing that I had checked 1.0.4 progs and thought there
was another older fsck you could run that time, but I have just double 
checked it and have found that 1.0.4 version I looked into was changed 
a bit. You are right, 1.0.4 works with the old format. and if you run it 
again with --check, you get rid of the ERROR flag in the super block.

-- 
Vitaly

Re: Full of surprises - A reiser4 story from userland

[Hans Reiser]

Fionn Behrens wrote:

>On Mi, 2005-09-28 at 18:25 +0400, Vitaly Fertman wrote:
>
>  
>
>>>2.6.11 refused to boot the
>>>root partition, claiming that there were an inconsistency in the FS.
>>>      
>>>
>>the disk format got new parameters and old kernels cannot understand it right.
>>    
>>
>
>Ah, I see. So maybe it would be a good idea if the new fs version would
>put up a big fat warning to syslog when it detects a partition written
>by a previous version, telling the user that he is about to break
>compatibility to his older version (and that the must upgrade userland
>tools, too!)
>  
>
Good idea.  Vitaly, please fix it.

>  
>
>>>Sep 28 08:44:20 rtfm kernel: WARNING: wrong pset member (11) for 42
>>>Sep 28 08:44:20 rtfm kernel: WARNING: unused space in inode 42
>>>      
>>>
>
>  
>
>>which fsck version?
>>    
>>
>
>1.0.4
>
>  
>
>>>the man page said that this would be read-only. 
>>>      
>>>
>>it says:
>>" --check
>>the default action checks the consistency and reports, but does not 
>>repair any corruption that it finds. This option may be used on a 
>>read-only file system mount.
>>"
>>it does not mean 100% read-only check. 
>>    
>>
>
>Okay, you sound a bit like a lawyer, but: you right me wrong.
>  
>
Vitaly, fix the docs.

>  
>
>>>There was my fourth surprise: This fsck thing had LIED to me; it was not
>>>read-only. 
>>>      
>>>
>>why do you think --build-fs is read-only? 
>>    
>>
>
>Had not gone --build-fs yet. This was still about --check.
>
>  
>
>>>It may have checked the fs read-only but it must have 
>>>treacherously flipped some "error" bit somewhere on disk
>>>      
>>>
>
>  
>
>>>Warning, mounting filesystem with fatal errors, forcing read-only mount
>>>(followed by the error from above)
>>>      
>>>
>>do you see anything relevant in the syslog?
>>    
>>
>
>That line was in the syslog.
>
>  
>
>>>So much for --check being just a check. I grabbed a book and lost about
>>>two more precious working hours running the --build-fs thing.
>>>      
>>>
>
>  
>
>>you need to clarify what reiser4progs version you are running.
>>1.0.5 fixes the fs to the letest format, which is needed for 2.6.13.
>>1.0.3 to the 2.6.10's one. 
>>    
>>
>
>1.0.4 . As I am now back on 2.6.11, I guess I should not upgrade to
>1.0.5 or would that not do harm anyway?
>
>thanks for answering!
>
>kind regards,
>		Fionn
>  
>

Re: Full of surprises - A reiser4 story from userland

[Ingo Bormuth]

On 2005-09-28 15:40, Fionn Behrens wrote:
> 
> There was my first surprise: It was not! I spent quite some time
> searching around and finally found that seemingly the only way to get
> reiser4 for the latest kernel were a dozen and a half reiser4* patches
> from mm. Their proper sequence of application also is up to the
> technically interested user.

A quite stable and easy to use patchset including reiser4 is called ArchCK 
and can be found at: http://iphitus.loudas.com/archck.php

I currently use 2.6.13-archck3.1 together with reiser4progs-1.0.5
and that works like charm.




-- 
Ingo Bormuth,  voicebox & telefax: +49-12125-10226517          '(~o-o~)'
GnuPG key 86326EC9 at http://ibormuth.efil.de/contact     ---ooO--(.)--Ooo---