From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marc - A. Dahlhaus Date: Fri, 27 Feb 2009 13:46:05 +0100 Subject: [Cluster-devel] cluster-3.0.0.alpha5 build problems against 2.6.28.7 ... In-Reply-To: <1235718355.27848.118.camel@cerberus.int.fabbione.net> References: <49A71395.4020904@wol.de> <1235718355.27848.118.camel@cerberus.int.fabbione.net> Message-ID: <49A7E08D.3010003@wol.de> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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