On 02/23/2011 10:00 AM, Fabio M. Di Nitto wrote: > On 2/23/2011 5:55 PM, Steven Dake wrote: >> On 02/23/2011 06:28 AM, Fabio M. Di Nitto wrote: >>> On 2/23/2011 2:17 PM, Russell Bryant wrote: >>>> On Wed, Feb 23, 2011 at 1:53 AM, Fabio M. Di Nitto <[email protected]> >>>> wrote: >>>>>> I hope the change from: >>>>>> read (fd, &memb_ring_id->seq, sizeof (unsigned long long)); >>>>>> to >>>>>> read (fd, &memb_ring_id->seq, sizeof (uint64_t)); >>>>>> >>>>>> won't cause any problems. >>>>> >>>>> On i686 i noticed the file being 8 bytes (unsigned long long)... I >>>>> wonder if you shutdown corosync, update packages with the fix, then >>>>> restart.. is it going to read garbage from the file? >>>> >>>> but sizeof (uint64_t) is also 8 bytes. >>> >>> ok... i clearly need more coffee :))) ok either x86_64 or i686 had a 4 >>> bytes file and the other 8... one of them is going to be affected by >>> switching to a different size. >>> >> >> Are you serious? It should be 8 bytes always! Could you give more >> details of your platform information (was it linux, which os version, etc) > > They were 2 VMs RHEL6.0+z one i386 and one x86_64. > > it´s entirely possible that the files were truncated somehow.. or that I > do not remember properly. > > Probably the same reason why x86_64 had a 0 bytes file.. go figure. > those vms are long gone now and as long as you have tested it, I am OK > with that. Don´t get my doubts in your way. > > Fabio
If there is some wierd platform specific issue that was making the data 4 bytes on disk, the new code will convert it to 8 bytes on disk. If inside corosync it is actually 4 bytes (which unsigned long long shouldn't be on rhel 6..:), (it is unsigned long long there in data structures as well) We would have serious i386->x86_64 communication problems which we don't see. _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
