Hi Amar,
So fix is what I did first, but someone was wondering about the
additional cost of the alignment calculation in the memory allocation
path. (Though, the unaligned write of the trailer might be as many
cycles of slowdown as a roundup calculation on platforms that handle
unaligned access in microcode).
The pull request with the fix is at:
https://github.com/gluster/glusterfs/pull/2669
With that, glusterd can now run on SPARC64 - without crashing in one of
the first few memory allocations.
Though, I still can not get glusterd on SPARC64 to sync up with the
pool. Whether with the trailer fixed, or the trailer removed. I end up
with cksum errors on /var/lib/glusterfs/ files - starting with a
completely clean /var/lib/glusterfs on the SPARC64 box.
The 2 big differences between the SPARC64 host and the other hosts that
are happily synced are:
- distro (SPARC64 is debian; others are Fedora)
- endianness.
Wondering if either of those could be a factor?
Thanks,
Paul
On Thu, 29 Jul 2021, Amar Tumballi wrote:
Thanks for the initiative Paul. Let me answer the major question from the
thread.
Remove the trailer? Or fix it?
Ideal one is to fix it, as we do use mem-pool info to identify leaks etc
through statedumps of the process. Remove can be an option on SPARC to
start with if fixing is time consuming. I recommend removing the trailer
within a #ifdef codeblock, so it may continue work in places where its
already working.
regards,
--
Paul Jakma | paul@xxxxxxxxx | @pjakma | Key ID: 0xD86BF79464A2FF6A
Fortune:
Honesty pays, but it doesn't seem to pay enough to suit some people.
-- F. M. Hubbard
-------
Community Meeting Calendar:
Schedule -
Every 2nd and 4th Tuesday at 14:30 IST / 09:00 UTC
Bridge: https://meet.google.com/cpu-eiue-hvk
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
https://lists.gluster.org/mailman/listinfo/gluster-devel
