[Cluster-devel] cluster-3.0.0.alpha5 build problems against 2.6.28.7 ...

Marc - A. Dahlhaus mad at wol.de
Fri Feb 27 12:46:05 UTC 2009


Hello Fabio,

Fabio M. Di Nitto schrieb:
> Hi Marc,
>
> On Thu, 2009-02-26 at 23:11 +0100, Marc - A. Dahlhaus wrote:
>   
>> Hello,
>>
>> just to let you all know, i had to do this to get gfs.ko to build:
>>
>> sed -i 's/__grab_cache_page/grab_cache_page/g' 
>> gfs-kernel/src/gfs/ops_address.c
>>     
>
> Abhi, could you please check if something has changed upstream that
> require this change?
>
>   
>> I'm in the middle of testing the release with my poor-mans test 
>> environment at home
>> consisting of a ggaoed ATA over Ethernet target and 3 x86_32 nodes. I'll 
>> report any
>> problems here when i get bitten by them.
>>     
>
> Thanks!
>
> Fabio
>
>   
Some simple tests with gfs and gfs2 resulted in no bigger problems but i
can't stress test it with my actual setup as the aoe target trows
commands away if the buffers get overloaded. I have to reconfigure it
before i can do some better stress testing with bonnie++ or some other
benchmark or test scenario you might suggest...

However i tested the storage-failure case (killing aoe target in the
middle of mount) and got some backtraces (from the withdrawing codepath)
and a hung up system (which i expected, so i didn't consider this as an
error :o).
I'll try to reproduce this over the next few days and catch anything
over serial console to post it here, maybe it could be of some use to
catch such errors better.

What i think is missing is a hint to create an ais user for corosync
startup, so the documentation in usage.txt isn't up to date anymore but
i could have missed something?!
I think the startup procedure for the applications changed also a bit in
stable3 so the usage.txt might need a larger rewrite.

By the way: Good work on the init scripts, they worked like a charm here
out of the box. I had to edit the stable2 ones quite a bit to get them
going.

Marc




More information about the Cluster-devel mailing list