kernel loop with lseek + LFS on reiser partition.

kernel loop with lseek + LFS on reiser partition.

[wolfgang.glas]

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

Hi all,

I was just about to report a seek bug in samba-2.2.3a, when I wrote the 
attached sample program seeking in a file to position 128GB from the 
beginning and the ne writing "HEllo, world!" to that position. The prgram 
closes fd's 0,1,2 before doing all that, because I tried to simulate the 
fd numbers of the samba server. Hence, error reporting goes to syslog(2) 
instead of stderr. (I recently read about sparse files and decided to give 
them a try...; Program compiled LFS support; see comment in C-file)

Running the program under SuSE7.3 with the folowing two kernels lets the 
process starve in an infineite loop inside the kernel (99% kernel CPU):

linux-2.4.16 from SuSE
linux-2.4.18 with the speedup patches from this mailing list plus 
lvm-1.0.3

glibc-2.2.4 (SuSE 7.3)

 No go with kill, kill -9...... Only reboot helps.

6GB Reiserfs partition on top of lvm, mount with -o conv. 

  Best regards,

    Wolfgang



--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas@ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31

Re: kernel loop with lseek + LFS on reiser partition.

[Oleg Drokin]

Hello!

   You seem to forgot to attach a program itself.

Bye,
    Oleg
On Mon, Apr 22, 2002 at 10:28:05AM +0200, wolfgang.glas@ev-i.at wrote:
> Hi all,
> 
> I was just about to report a seek bug in samba-2.2.3a, when I wrote the 
> attached sample program seeking in a file to position 128GB from the 
> beginning and the ne writing "HEllo, world!" to that position. The prgram 
> closes fd's 0,1,2 before doing all that, because I tried to simulate the 
> fd numbers of the samba server. Hence, error reporting goes to syslog(2) 
> instead of stderr. (I recently read about sparse files and decided to give 
> them a try...; Program compiled LFS support; see comment in C-file)
> 
> Running the program under SuSE7.3 with the folowing two kernels lets the 
> process starve in an infineite loop inside the kernel (99% kernel CPU):
> 
> linux-2.4.16 from SuSE
> linux-2.4.18 with the speedup patches from this mailing list plus 
> lvm-1.0.3
> 
> glibc-2.2.4 (SuSE 7.3)
> 
>  No go with kill, kill -9...... Only reboot helps.
> 
> 6GB Reiserfs partition on top of lvm, mount with -o conv. 
> 
>   Best regards,
> 
>     Wolfgang
> 
> 
> 
> --
> Dr. Wolfgang Glas                        EV-i Informationstechnologie 
> GmbH.
> Gesch?ftsf?hrer                          Sebastian-Kneipp-Weg 17
> Wolfgang.Glas@ev-i.at                    A-6020 Innsbruck/Austria
> phone: ++43-512-284883-2                 fax: ++43-512-281624-31

Re: kernel loop with lseek + LFS on reiser partition.

[Oleg Drokin]

Hello!

On Mon, Apr 22, 2002 at 10:28:05AM +0200, wolfgang.glas@ev-i.at wrote:

> Running the program under SuSE7.3 with the folowing two kernels lets the 
> process starve in an infineite loop inside the kernel (99% kernel CPU):

Ok, now having done more research, I must say it is not infinite loop
in fact:
green@angband:~/work/bugs> gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -Wall -o t testprg.c
testprg.c: In function `main':
testprg.c:47: warning: use of `l' length character with `f' type character
testprg.c:54: warning: control reaches end of non-void function
green@angband:~/work/bugs> time ./t

real    6m20.958s
user    0m0.000s
sys     6m22.430s

I think this is because of expanding-truncate patch.
So, the real bug is this process cannot get interrupted until finished
which opens a window for resource-eating.

>  No go with kill, kill -9...... Only reboot helps.

How long have you tried to wait?

Bye,
    Oleg

Re: kernel loop with lseek + LFS on reiser partition.

[wolfgang.glas]

First, I have to apologize, that the program does not return 0 from 
main(), because I crufted this together in 5 minutes or so...

Concerning your question about how long I tried to wait:

It really seems, that I haven't been as patient as you. I'd say I waited 
for 5 minutes or so. (maybe less...)

(833 MHz PIII, EIDE-HD)

  Regards,

    Wolfgang

--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas@ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31

Re: kernel loop with lseek + LFS on reiser partition.

[Oleg Drokin]

Hello!

On Mon, Apr 22, 2002 at 11:49:47AM +0200, wolfgang.glas@ev-i.at wrote:

> First, I have to apologize, that the program does not return 0 from 
> main(), because I crufted this together in 5 minutes or so...

This is not a problem at all. I just shown that I compiled a program with
correct gcc parameters.

> Concerning your question about how long I tried to wait:
> It really seems, that I haven't been as patient as you. I'd say I waited 
> for 5 minutes or so. (maybe less...)
> (833 MHz PIII, EIDE-HD)

I have dual AthlonMP-1700+. IDE HDD. (though no HDD access is made).

Can you verify that your program in fact finishes for you too after some time?

Bye,
    Oleg

Re: kernel loop with lseek + LFS on reiser partition.

[wolfgang.glas]

OK, The program terminates.
During lunchtime, I gave it a try and what I've got is:

/home/wglas/tmp > gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 
-D_GNU_SOURCE seek.c
/home/wglas/tmp > time ./a.out

real    11m35.661s
user    0m0.000s
sys     11m32.780s

Seems to scale linear with CPU power......

kernel: 2.4.18+speedup patches.

   Wolfgang

--
Dr. Wolfgang Glas                        EV-i Informationstechnologie 
GmbH.
Geschäftsführer                          Sebastian-Kneipp-Weg 17
Wolfgang.Glas@ev-i.at                    A-6020 Innsbruck/Austria
phone: ++43-512-284883-2                 fax: ++43-512-281624-31

Re: kernel loop with lseek + LFS on reiser partition.

[Oleg Drokin]

Hello!

On Mon, Apr 22, 2002 at 01:30:58PM +0200, wolfgang.glas@ev-i.at wrote:

> OK, The program terminates.

Good.

> Seems to scale linear with CPU power......

As expected. I am experimenting in 2 directions currently:
One is to speed up the lenghtly operation itself ( got cpu time spent down
to 8 seconds already, but some problems still persists).
Another one is to simply allow for this process to be terminated.

Bye,
    Oleg

Re: kernel loop with lseek + LFS on reiser partition.

[Oleg Drokin]

Hello!

On Mon, Apr 22, 2002 at 07:10:16PM +0200, Dieter N?tzel wrote:

> > I think this is because of expanding-truncate patch.
> > So, the real bug is this process cannot get interrupted until finished
> > which opens a window for resource-eating.

> /database/db1> time ~/Entwicklung/ReiserFS/testprg
> 0.000u 545.310s 9:12.69 98.6%   0+0k 0+0io 124pf+0w

9 minutes as expected from your HW config.

> -rw-r--r--    1 nuetzel  users    137438953485 Apr 22 17:22 seek.tmp
> /dev/sdb5               859412    166264    693148  20% /database/db1
> Isn't this only a "bad" glibc "speed test"?

Huh? glibc have nothing to do with this result.

> With my latest latencytest0.42-png tests I found that there are one or two 
> locks remaining in the VFS or ReiserFS code (preemption and/or lock-break 
> could be the culprit, too).

We already have identified a problem place and testing the patch before
releasing it to the public.

Bye,
    Oleg