Re: Perfomance problem backupscript

Hi,

>> I wrote:
>> You should try to find out wether the bottleneck is in
>> - filesystem crawling performance
>
> Joerg Schilling wrote:
> A known problem on Linux

I know. I suffer.


>> - star reading, formatting, transfer performance
> Did never cause any problem

It has to deal with the system service offered.
You have to expect unexpected things to happen in 
this service. (I love it to be that precise :))


>> I bet star crawls better than find, btw.
> GNU find is broken and by default ignores POSIX semantics.
> This results in much "better performance" than you observe
> with correctly written programs. Either use sfind or
> add the -noleaf option to GNUfind.

What ? Even slower ?

I crawled (still crawl in the stable version) by an old
quick-hack using popen("ls -a1","r") which i identified
as malicious memory waster, recently.
When i employed readdir() instead, i experienced a
dramatic drop in throughput in overcrowded directories.
The culprit turned out to be the interchanged calls of
readdir() and stat(). Some readdir() buffering helped
much and now it clearly outperforms the ls-hack.
Nevertheless the performance of ext2 and reiserfs with
stat() in fat directories is a big disappointment.

Remarkable: in those filthy directories, find does only
half as good as ls (which sorts the giant list !).


> On a OS where star is faster when -no-fifo is used, you could
> asume that this OS is broken. 

And if one has some technical facts to show then one
might even convince the CTO that there is need to act.


Have a nice day :)

Thomas