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

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

[Marc - A. Dahlhaus]

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

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.

Marc

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

[Fabio M. Di Nitto]

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

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

[Marc - A. Dahlhaus]

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

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

[Fabio M. Di Nitto]

On Fri, 2009-02-27 at 13:46 +0100, Marc - A. Dahlhaus wrote:
> 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...

That's good news. Take your time.

> 
> 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).

It would be important to see those anyway to make sure they are coming
from the correct layer.

> 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.

Yes absolutely.

> 
> 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?!

Corosync documentation has those info as they belong there.

> I think the startup procedure for the applications changed also a bit in
> stable3 so the usage.txt might need a larger rewrite.

Yes, we know that most of the documentation needs to be updated for
stable3 and it's going to happen soonish since we are about to approach
beta/rc/final.

> 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.

great! nice to know!

Thanks a lot for your testing! It's really appreciated

Fabio