hans! i found a bug in reiser4 :((((

hans! i found a bug in reiser4 :((((

[Redeeman]

im very sorry to announce it, but i found a bug :(

glibc wont compile on a reiser4 filesystem, it makes no sense at all,
but it wont. :( PLEASE tell me its not reiser4's fault!


-- 
Regards, Redeeman
()  ascii ribbon campaign - against html e-mail 
/\                        - against microsoft attachments

Re: hans! i found a bug in reiser4 :((((

[aquadog]

I'm having the exact same problem. Doing a gentoo stage1 install,
and it fails on glibc every time. Exact same configuraiton on reiser3 
partition and it works no problem.

It happens while making a call to syscall.h and returns a "nested too 
deep" error.

Used all the latest patches I got from namesys.com.

Redeeman wrote:
> im very sorry to announce it, but i found a bug :(
> 
> glibc wont compile on a reiser4 filesystem, it makes no sense at all,
> but it wont. :( PLEASE tell me its not reiser4's fault!
> 
> 

Re: hans! i found a bug in reiser4 :((((

[Vladimir Saveliev]

Hello

On Sun, 2004-04-11 at 19:50, Redeeman wrote:
> im very sorry to announce it, but i found a bug :(
> 
> glibc wont compile on a reiser4 filesystem, it makes no sense at all,
> but it wont. :( PLEASE tell me its not reiser4's fault!
> 

Do you mean that you put glibc sources on reiser4 and that make fails?

Re: hans! i found a bug in reiser4 :((((

[Hendrik Visage]

On Mon, Apr 12, 2004 at 11:44:10AM +0400, Vladimir Saveliev wrote:
> On Sun, 2004-04-11 at 19:50, Redeeman wrote:
> > 
> > glibc wont compile on a reiser4 filesystem, it makes no sense at all,
> > but it wont. :( PLEASE tell me its not reiser4's fault!
> 
> Do you mean that you put glibc sources on reiser4 and that make fails?

That's how I understood them.

Re: hans! i found a bug in reiser4 :((((

[aquadog]

That is correct.

Vladimir Saveliev wrote:
> Hello
> 
> 
> Do you mean that you put glibc sources on reiser4 and that make fails?
> 
> 

Re: hans! i found a bug in reiser4 :((((

[Thomas Graham]

it seems a very serious problem, are you sure that the problem is come
from reiserfs4 ? did you put optimize tag to none when you compile glibc ?
because glibc is very sensative on optimize tag, please post the error
section to mail list, so that people could help for that, I hope that's
not reiser4 problem, errrr...


> That is correct.
>
> Vladimir Saveliev wrote:
>> Hello
>>
>>
>> Do you mean that you put glibc sources on reiser4 and that make fails?
>>
>>
>
>


-- 
HK Celtic Orchestra leader and coordanator: Thomas Graham Lau
Phone number: 852-93239670    (24hours a day, 7days a week non-stop phone)
Web site: http://sml.dyndns.org
Email: lkthomas@sml.dyndns.org

Re: hans! i found a bug in reiser4 :((((

[Redeeman]

i noticed this while trying to do a livecd with gentoos cataylst, i
thught it would help speeding up on a reiser4 partition.

before that i read on the forums that it didnt compile on reiser4, but i
thought "wtf! lamer! why wouldnt it?!"

but when i moved the build to reiser4 partition, it failed. moving back
to reiserfs partition, and it builds. with absolutely no change other
than the fs change. and for cflags, im just using standard. no
optimization at all.


On Mon, 2004-04-12 at 12:40, Thomas Graham wrote:
> it seems a very serious problem, are you sure that the problem is come
> from reiserfs4 ? did you put optimize tag to none when you compile glibc ?
> because glibc is very sensative on optimize tag, please post the error
> section to mail list, so that people could help for that, I hope that's
> not reiser4 problem, errrr...
> 
> 
> > That is correct.
> >
> > Vladimir Saveliev wrote:
> >> Hello
> >>
> >>
> >> Do you mean that you put glibc sources on reiser4 and that make fails?
> >>
> >>
> >
> >
-- 
Regards, Redeeman
redeeman@metanurb.dk

Re: hans! i found a bug in reiser4 :((((

[Mike Houston]

Hello

I think that I have experienced a related problem.

I'm not subscribed to this list, but I tried the 2004.03.26 snapshot, applying all.diff.gz to the 2.6.5-rc2 kernel, booted with it, built the tools and created a reiser4 filesystem (using exact command given) on my "scratch" partition. I keep source trees and compile all my software on that partition.

I was otherwise impressed with it, but there seems to be a problem, I'm guessing with timestamps, that causes the make utility to treat files as being modified. The most obvious symptom is that make issues commands to recompile just about everything on the make install. I didn't have anything fail to compile (I didn't have cause to do a build of glibc), it just had to do a pile of extra work.

I've refrained from reporting this as a bug, because I'm unsure if it's a reiser4 bug, or a problem with utilities like coreutils or make that need to be brought up to speed, or a problem with the kernel itself in relation to reiser4. This does not occur on any of my ext2 partitions. fsck.reiser4 --check was not finding any problems with the filesystem either. (it was otherwise GREAT)

I am checking these list archives, and waiting for the next snapshot, to try again in earnest, but for now I no longer have the reiser4 filesystem. (I needed full use of that partition back again and wanted to move on with 2.6.5)

Gnu Make 3.80
Coreutils 5.2.1
gcc 3.3.3
binutils 2.14.90.0.8

If you want to know anything else about my system, let me know.

Mike Houston

---------- Quoted Text Follows---------------------

List:       reiserfs
Subject:    Re: hans! i found a bug in reiser4 :((((
From:       Redeeman <redeeman () metanurb ! dk>
Date:       2004-04-12 11:05:05
Message-ID: <1081767905.8170.3.camel () redeeman ! linux ! dk>
[Download message RAW]

i noticed this while trying to do a livecd with gentoos cataylst, i
thught it would help speeding up on a reiser4 partition.

before that i read on the forums that it didnt compile on reiser4, but i
thought "wtf! lamer! why wouldnt it?!"

but when i moved the build to reiser4 partition, it failed. moving back
to reiserfs partition, and it builds. with absolutely no change other
than the fs change. and for cflags, im just using standard. no
optimization at all.


On Mon, 2004-04-12 at 12:40, Thomas Graham wrote:
> it seems a very serious problem, are you sure that the problem is come
> from reiserfs4 ? did you put optimize tag to none when you compile glibc ?
> because glibc is very sensative on optimize tag, please post the error
> section to mail list, so that people could help for that, I hope that's
> not reiser4 problem, errrr...
> 
> 
> > That is correct.
> >
> > Vladimir Saveliev wrote:
> >> Hello
> >>
> >>
> >> Do you mean that you put glibc sources on reiser4 and that make fails?
> >>
> >>
> >
> >
-- 
Regards, Redeeman

Re: hans! i found a bug in reiser4 :((((

[Todd Lyons]

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

aquadog wanted us to know:

>I'm having the exact same problem. Doing a gentoo stage1 install,
>and it fails on glibc every time. Exact same configuraiton on reiser3 
>partition and it works no problem.

I got all excited when I first read this because I am having stability
problems on my Gentoo box with a lone ReiserFS (3.6).  So I'm going to
rebuild glibc with no optimizations, but I'm not running reiser4, so my
results will probably have no bearing on things.  Doesn't hurt to try
though.

- -- 
Blue skies...	Todd                   http://www.mrball.net
        Public key:  http://www.mrball.net/todd.asc
        Signing an email is like wearing underwear.  
  You don't have to, but it's a really good idea to do it.
Linux kernel 2.4.22-12.tmb.1mdk   2 users,  load average: 0.22, 0.05, 0.02
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: http://www.mrball.net/todd.asc

iD8DBQFAhGGgIBT1264ScBURAm0BAJ9rewJB82iXZinWVaAx9K32mP1v4ACfWUa+
Sy9URjQSK4tbXS7rdnFaU94=
=QhXE
-----END PGP SIGNATURE-----

Re: hans! i found a bug in reiser4 :((((

[Jeffrey Rice]

I would also like to confirm the bug with glibc and reiser4.  If I try to 
compile with my /usr as Reiser4, I get an "#include nested too deeply" 
error in syscalls.h.  If /usr is any other fs type, no problems.  It's hard 
to believe the fs should be the cause but it really appears to be the case.


*       *       *       *       *       *       *
Jeffrey Rice    ||     jeffrice@finity.org      ||  www.finity.org

Re: hans! i found a bug in reiser4 :((((

[Jason Stubbs]

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

On Wednesday 21 April 2004 04:14, Jeffrey Rice wrote:
> I would also like to confirm the bug with glibc and reiser4.  If I try to
> compile with my /usr as Reiser4, I get an "#include nested too deeply"
> error in syscalls.h.  If /usr is any other fs type, no problems.  It's hard
> to believe the fs should be the cause but it really appears to be the case.

+1

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQIXCgVoikN4/5jfsAQKwWAQAtKAlc98fWOHCmlvoE9SW+PtcvddYifZj
e0kMv0zXF8bytZpfMQi9A/eNgK1Th6+tkUg1YB6VvbnKjW1e1KzfCEX70SkOYwes
SmJdaTclH9Nmmsvhq6elIJQCYBM4rVVs1FYLeOwr8vQw5ZeJYRUrO6ItOQYg8eso
X2wi78eaqVc=
=+ine
-----END PGP SIGNATURE-----

Re: hans! i found a bug in reiser4 :((((

[David Masover]

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

Todd Lyons wrote:
| aquadog wanted us to know:
|
|
|>>I'm having the exact same problem. Doing a gentoo stage1 install,
|>>and it fails on glibc every time. Exact same configuraiton on reiser3
|>>partition and it works no problem.

Not sure if I just missed this message before, but I get the same issue.
~ If I take a more complete gentoo installation, I get more errors. It
seems to me the most fundamental errors (causing all the others) are as
follows:

file is missing:   maybe the file got lost.  Maybe it got truncated to 0
length.  Maybe it was just the way I tarred it up before, but I found
/bin/X to be of mode 0000, length 0.  Later on, either X finally merged
properly (I don't think so) or it magically fixed itself, but the file
magically appeared and worked.  (This email comes from Mozilla
Thunderbird on that box.)

make runs in an infinite loop.  I can't figure this out at all.  It
happens with glibc and quite a few other things.  It appears to be
running several 'gcc' commands somewhat faster than usual, only it runs
them, exits the directory, enters the exact same directory, runs the
exact same commands again.  Noticed this problem because 'make'
processes usually don't use 100% cpu and/or 15 hours of cpu time on
modern (1.7 ghz) boxes, even for glibc.

The filesystem appears rock solid, except things don't compile, and I
don't like 'metas'.  After watching (and boldly and stupidly
participating) in the 'metas' thread, '...' looks cool, but I'd accept
anything that won't hurt my backups.  (Ok, my brother cleverly keeps his
pr0n stash in a file called '...' in his home, but he'll just have to
explain to me exactly which files got clobbered when I untar it onto the
next release of v4.)

I am going to test this on xfs for a bit, see if it compiles properly.
If it does, I'm sitting out until the next snapshot.

Speaking of which,  when is the next snapshot?  Or where can I get the
best-working copy?  I've seen a few patches float through this list, but
I can't possibly keep track of them all.  I at least want a patch to let
me compile things again!

I should add a few more points before I forget it -- v4 is nice on my
laptop, but now I want encryption.  Should I try to write/find an
encryption plugin, or use cryptoloop/dm-crypto?

In general, with a finished v4 and quotas (or even size limits on
directories, could this be a plugin?), is there still a logical reason
to put things on separate partitions?  I can only think of these reasons
right now:

size:  when /var fills up, you can't log.  When /tmp fills up, certain
programs stop working.  When /usr fills up, you can't install new
programs.  When /home fills up, users can't create new files.  These
should not happen all at once, and should not happen just because
someone made a huge amount of /tmp files.  However, most users aren't
that paranoid, and the ones who are would probably rather create
something more flexible than even lvm + resizefs + lots of tiny
partitions.  Some sort of quota, per-directory rather than per-user,
would accomplish the same thing, although per-user quotas are more than
enough for most things anyway.

setuid hardlinks:  if the user has write access to anywhere on a
partition with setuid root programs, they can create their own personal
hardlinked copy of the file, and when a vulnerability is discovered and
the original is unlinked, they still have their copy, still with the
setuid bit.  The best trick here is to patch package managers (and maybe
make, too) to change a file's mode to 0000, then forceably remove it.
The permissions are shared across hardlinks, so the malicious user is
left with a pointless file.  The alternative is to shred the file before
delete, which has performance problems, and is still risky -- the user
gets to run a null or random file as root.

fragmentation:  /tmp changes much, much faster than /usr.  This is part
of why you see Windows getting so fragmented -- rapid creation and
deletion of temporary files left parts of the disk looking like Swiss
Cheese, and then the user went to install a program...  With a decent
amount of RAM and reiser4, the filesystem can be intelligent enough
about writing the data that most data wouldn't be very fragmented on a
first write -- and then there's the repacker.  Also, a lot of temporary
files (if not most) are so small and so transient that they may never
touch the disk on reiser4, while they'd wreak havok on ext3.

isolation:  if there's a bad block or a kernel crash/bug or any number
of doomsday scenarios and one filesystem is blown away, if that
filesystem is /tmp, you're fine.  If that filesystem is /usr, you'll be
down for awhile, and if it's /home, you may have lost some crucial data.
~ However, reiser3, ext3, and xfs all seem so stable (and reiser4 looks
like it will be as stable) that no software bug is going to clobber your
entire filesystem, and with reiser4's atomicness, a crash won't even
corrupt anything (it'll just lose the data it'd lose anyway).  Also, if
the disk is bad, I'd buy a new one, and by the time the disk is bad or
something's so wrong that a superblock gets clobbered, I should have
backups anyway.

having a huge number of files:  if I remember correctly, reiser4
supports ~2^64 files.  That's 18446744073709551616!  If you have more
than that, I hope you work for a big enough organization that you can
afford to pay some hacker to extend that to 2^128.  If that cripples
performance, you can buy more performance.  Personally, I still can't
grasp that number -- counting every file on my system, I ended up with
only ~250000 last I checked.

Am I missing something important here?  Or should I go with the newbie's
partitioning scheme (hda1 is boot, hda2 is /, hda3 is swap)?




Disclaimer:  If anything I say is offensive or inappropriate, tell me
about it.  If you aren't offensive in how you point it out, I might be
more careful in the future.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQIXRrHgHNmZLgCUhAQK5LBAAla82/D+4OKdjY4pwJ9zJKvRpf7b5OXjY
U7Up9LvnImcvLV+NscXKJJcwaYDeY/PxxtgOG+OYzMJIf87/qFgFb3aMM5M2h+rN
pSjkmv4e4xV9MaJSskLV03jJYRO7yRwY6FTI6QRkJFhJAkav8aQgTePbZnqnriRs
AxBgZsnNa6EuuhQZxniTxi6L58SP6cGyW9Y8efvy3L8E/xNKcmIhPgY59yrNxaFp
8FaQNXcK/TgcTbVQpIBJw4B/PIWISi5f/5CNqnZOITvKTCM09wRMQgrteYo16sD1
G7TYNGFYfpgoJsUE/nj69iHTWQET4WLSPF+X3dPsDXluaJ+9FuDe0d+BTAA+1fXI
Ek4mXe7hkhOBMJsCMSsY318BNVUuWKxd+Vk13XrdEIuhYg2zJvozGEFd2miRAZdS
8MXjWBuQ/6zL0P9Qz5JfceKS/1o2ixfbWJxudfRX3PbWnKjbMU7WYn9Zr5+4tfus
MUx3j/hv5WgMbn6OIGshUXKNjGMNB9yJZ8c4a8E29MD9UeN4Lgk8fQMONWAr2gBN
gk/k5JrxGADwl0lNj3Agifthicj3TDEitdfbUgqnlLq3Zm848uGFnQ4qJQYHdeBH
Sxa73aDVUyhRyekm0fLTQk65Gv+sdATveOmkZ4o+8KzzKt+8KKlu6EgVuzM9NjB0
ZIbvPeXytxw=
=dNFn
-----END PGP SIGNATURE-----

Re: hans! i found a bug in reiser4 :((((

[Vladimir Saveliev]

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

Hello

On Wed, 2004-04-21 at 05:43, David Masover wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Todd Lyons wrote:
> | aquadog wanted us to know:
> |
> |
> |>>I'm having the exact same problem. Doing a gentoo stage1 install,
> |>>and it fails on glibc every time. Exact same configuraiton on reiser3
> |>>partition and it works no problem.
> 
> Not sure if I just missed this message before, but I get the same issue.
> ~ If I take a more complete gentoo installation, I get more errors. It
> seems to me the most fundamental errors (causing all the others) are as
> follows:
> 
> file is missing:   maybe the file got lost.  Maybe it got truncated to 0
> length.  Maybe it was just the way I tarred it up before, but I found
> /bin/X to be of mode 0000, length 0.  Later on, either X finally merged
> properly (I don't think so) or it magically fixed itself, but the file
> magically appeared and worked.  (This email comes from Mozilla
> Thunderbird on that box.)
> 
> make runs in an infinite loop.  I can't figure this out at all.  It
> happens with glibc and quite a few other things.  It appears to be
> running several 'gcc' commands somewhat faster than usual, only it runs
> them, exits the directory, enters the exact same directory, runs the
> exact same commands again.  Noticed this problem because 'make'
> processes usually don't use 100% cpu and/or 15 hours of cpu time on
> modern (1.7 ghz) boxes, even for glibc.
> 

This bug is fixed. Would you please tyr with the attached patch?


> The filesystem appears rock solid, except things don't compile, and I
> don't like 'metas'.  After watching (and boldly and stupidly
> participating) in the 'metas' thread, '...' looks cool, but I'd accept
> anything that won't hurt my backups.  (Ok, my brother cleverly keeps his
> pr0n stash in a file called '...' in his home, but he'll just have to
> explain to me exactly which files got clobbered when I untar it onto the
> next release of v4.)
> 
> I am going to test this on xfs for a bit, see if it compiles properly.
> If it does, I'm sitting out until the next snapshot.
> 
> Speaking of which,  when is the next snapshot? 

We want to fix few problems which are both hard to hit and to fix.
Then snapshot will be issued.

>  Or where can I get the
> best-working copy?  I've seen a few patches float through this list, but
> I can't possibly keep track of them all.  I at least want a patch to let
> me compile things again!
> 
> I should add a few more points before I forget it -- v4 is nice on my
> laptop, but now I want encryption.  Should I try to write/find an
> encryption plugin, or use cryptoloop/dm-crypto?
> 
I do not think that cryptoplugin is in working state already. Also I
think that now it is not easy to write it without being familar with
reiser4 internals.

> In general, with a finished v4 and quotas (or even size limits on
> directories, could this be a plugin?), is there still a logical reason
> to put things on separate partitions?  

IMHO, this remains a matter of user preferences and tasks a machine is
performing.

> I can only think of these reasons
> right now:
> 
> size:  when /var fills up, you can't log.  When /tmp fills up, certain
> programs stop working.  When /usr fills up, you can't install new
> programs.  When /home fills up, users can't create new files.  These
> should not happen all at once, and should not happen just because
> someone made a huge amount of /tmp files.  However, most users aren't
> that paranoid, and the ones who are would probably rather create
> something more flexible than even lvm + resizefs + lots of tiny
> partitions.  Some sort of quota, per-directory rather than per-user,
> would accomplish the same thing, although per-user quotas are more than
> enough for most things anyway.
> 
> setuid hardlinks:  if the user has write access to anywhere on a
> partition with setuid root programs, they can create their own personal
> hardlinked copy of the file, and when a vulnerability is discovered and
> the original is unlinked, they still have their copy, still with the
> setuid bit.  The best trick here is to patch package managers (and maybe
> make, too) to change a file's mode to 0000, then forceably remove it.
> The permissions are shared across hardlinks, so the malicious user is
> left with a pointless file.  The alternative is to shred the file before
> delete, which has performance problems, and is still risky -- the user
> gets to run a null or random file as root.
> 
> fragmentation:  /tmp changes much, much faster than /usr.  This is part
> of why you see Windows getting so fragmented -- rapid creation and
> deletion of temporary files left parts of the disk looking like Swiss
> Cheese, and then the user went to install a program...  With a decent
> amount of RAM and reiser4, the filesystem can be intelligent enough
> about writing the data that most data wouldn't be very fragmented on a
> first write -- and then there's the repacker.  Also, a lot of temporary
> files (if not most) are so small and so transient that they may never
> touch the disk on reiser4, while they'd wreak havok on ext3.
> 
> isolation:  if there's a bad block or a kernel crash/bug or any number
> of doomsday scenarios and one filesystem is blown away, if that
> filesystem is /tmp, you're fine.  If that filesystem is /usr, you'll be
> down for awhile, and if it's /home, you may have lost some crucial data.
> ~ However, reiser3, ext3, and xfs all seem so stable (and reiser4 looks
> like it will be as stable) that no software bug is going to clobber your
> entire filesystem, and with reiser4's atomicness, a crash won't even
> corrupt anything (it'll just lose the data it'd lose anyway).  Also, if
> the disk is bad, I'd buy a new one, and by the time the disk is bad or
> something's so wrong that a superblock gets clobbered, I should have
> backups anyway.
> 
> having a huge number of files:  if I remember correctly, reiser4
> supports ~2^64 files.  That's 18446744073709551616!  If you have more
> than that, I hope you work for a big enough organization that you can
> afford to pay some hacker to extend that to 2^128.  If that cripples
> performance, you can buy more performance.  Personally, I still can't
> grasp that number -- counting every file on my system, I ended up with
> only ~250000 last I checked.
> 
> Am I missing something important here?  Or should I go with the newbie's
> partitioning scheme (hda1 is boot, hda2 is /, hda3 is swap)?
> 
> 
> 
> 
> Disclaimer:  If anything I say is offensive or inappropriate, tell me
> about it.  If you aren't offensive in how you point it out, I might be
> more careful in the future.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iQIVAwUBQIXRrHgHNmZLgCUhAQK5LBAAla82/D+4OKdjY4pwJ9zJKvRpf7b5OXjY
> U7Up9LvnImcvLV+NscXKJJcwaYDeY/PxxtgOG+OYzMJIf87/qFgFb3aMM5M2h+rN
> pSjkmv4e4xV9MaJSskLV03jJYRO7yRwY6FTI6QRkJFhJAkav8aQgTePbZnqnriRs
> AxBgZsnNa6EuuhQZxniTxi6L58SP6cGyW9Y8efvy3L8E/xNKcmIhPgY59yrNxaFp
> 8FaQNXcK/TgcTbVQpIBJw4B/PIWISi5f/5CNqnZOITvKTCM09wRMQgrteYo16sD1
> G7TYNGFYfpgoJsUE/nj69iHTWQET4WLSPF+X3dPsDXluaJ+9FuDe0d+BTAA+1fXI
> Ek4mXe7hkhOBMJsCMSsY318BNVUuWKxd+Vk13XrdEIuhYg2zJvozGEFd2miRAZdS
> 8MXjWBuQ/6zL0P9Qz5JfceKS/1o2ixfbWJxudfRX3PbWnKjbMU7WYn9Zr5+4tfus
> MUx3j/hv5WgMbn6OIGshUXKNjGMNB9yJZ8c4a8E29MD9UeN4Lgk8fQMONWAr2gBN
> gk/k5JrxGADwl0lNj3Agifthicj3TDEitdfbUgqnlLq3Zm848uGFnQ4qJQYHdeBH
> Sxa73aDVUyhRyekm0fLTQk65Gv+sdATveOmkZ4o+8KzzKt+8KKlu6EgVuzM9NjB0
> ZIbvPeXytxw=
> =dNFn
> -----END PGP SIGNATURE-----
> 

[-- Attachment #2: tail.c.diff --]
[-- Type: text/plain, Size: 914 bytes --]

--- tail.c~	2004-04-13 18:18:52.000000000 +0400
+++ tail.c	2004-04-13 18:20:14.000000000 +0400
@@ -463,12 +463,18 @@
 	}
 
 	inode = mapping->host;
-	if (get_key_offset(&f->key) > inode->i_size)
+	if (get_key_offset(&f->key) > inode->i_size) {
+		assert("vs-1649", f->user == 1);
 		INODE_SET_FIELD(inode, i_size, get_key_offset(&f->key));
-	inode->i_ctime = inode->i_mtime = CURRENT_TIME;
-	result = reiser4_update_sd(inode);
-	if (result)
-		return result;
+	}
+	if (f->user != 0) {
+		/* this was writing data from user space. Update timestamps, therefore. Othrewise, this is tail
+		   conversion where we should not update timestamps */
+		inode->i_ctime = inode->i_mtime = CURRENT_TIME;
+		result = reiser4_update_sd(inode);
+		if (result)
+			return result;
+	}
 
 	/* FIXME-VS: this is temporary: the problem is that bdp takes inodes
 	   from sb's dirty list and it looks like nobody puts there inodes of

Re: hans! i found a bug in reiser4 :((((

[Vladimir Saveliev]

Hello

On Tue, 2004-04-20 at 23:14, Jeffrey Rice wrote:
> I would also like to confirm the bug with glibc and reiser4.  If I try to 
> compile with my /usr as Reiser4, I get an "#include nested too deeply" 
> error in syscalls.h.  If /usr is any other fs type, no problems.  It's hard 
> to believe the fs should be the cause but it really appears to be the case.
> 

I moved my suse9.0's /usr to reiser4 and performed the following:
cd /usr/src
mkdir compiling-glibc
cd compiling-glibc
tar jxf /tmp/glibc-2.3.2.tar.bz2
cd glibc-2.3.2
tar jxf /tmp/glibc-linuxthreads-2.3.2.tar.bz2
cd ..
./glibc-2.3.2/configure --enable-add-ons=linuxthreads --prefix=/usr
make

this did not hit "#include nested too deeply"

it ended up with 
sscanf.c:31: warning: conflicting types for built-in function `sscanf'
sscanf.c: In function `sscanf':
sscanf.c:37: error: `va_start' used in function with fixed args
make[2]: *** [/usr/ttt/stdio-common/sscanf.o] Error 1
make[2]: Leaving directory `/usr/ttt/glibc-2.3.2/stdio-common'
make[1]: *** [stdio-common/subdir_lib] Error 2
make[1]: Leaving directory `/usr/ttt/glibc-2.3.2'
make: *** [all] Error 2


It does so regardless to what filesystem holds /usr.
Would you please instruct me how to reproduce your problem?


> 
> *       *       *       *       *       *       *
> Jeffrey Rice    ||     jeffrice@finity.org      ||  www.finity.org
> 
> 
> 
> 
> 

Re: hans! i found a bug in reiser4 :((((

[Hans Reiser]

When is the next snapshot coming out, it is overdue....

Re: hans! i found a bug in reiser4 :((((

[Redeeman]

the tail.c.diff patch fixed this

On Tue, 2004-04-20 at 21:14, Jeffrey Rice wrote:
> I would also like to confirm the bug with glibc and reiser4.  If I try to 
> compile with my /usr as Reiser4, I get an "#include nested too deeply" 
> error in syscalls.h.  If /usr is any other fs type, no problems.  It's hard 
> to believe the fs should be the cause but it really appears to be the case.
> 
> 
> *       *       *       *       *       *       *
> Jeffrey Rice    ||     jeffrice@finity.org      ||  www.finity.org
> 
> 
-- 
Regards, Redeeman
()  ascii ribbon campaign - against html e-mail 
/\                        - against microsoft attachments

Re: hans! i found a bug in reiser4 :((((

[Vladimir Saveliev]

Hello

On Wed, 2004-04-21 at 19:43, Hans Reiser wrote:
> When is the next snapshot coming out, it is overdue....

iozone still does not work. nfs just started to work better today,
though.

> 
> 
> 

Re: hans! i found a bug in reiser4 :((((

[Nikita Danilov]

Hans Reiser writes:
 > When is the next snapshot coming out, it is overdue....

What kernel snapshot should be released against?

 > 
 > 

Nikita.