Hello team - as always, thanks so much for Gluster. We're trying to finalize validation to move from glusterfs 7.9 to glusterfs 9.3. We have to do an intensive validation the best we can on internal clusters pretending we have clusters like Frontier with around 10K compute nodes. This background is just so you understand why we can't jump frequently to the very latest. This started a couple months back. Anyway, on our head node of the cluster -- which is not a gluster server but a fuse mount consumer - we have always used a highly available IP address (we use CTDB on the gluster side) for the fstab entry. That is, the glusterfs entry on our head node points to an IP alias that connects to one of the gluster serves. This worked fine for us. When we migrated to glusterfs9.3, we began to see this error in the fuse mount log: 'duplicate entry for volfile-server' (LG_MSG_DUPLICATE_ENTRY, LG_MSG_DUPLICATE_ENTRY_STR) It doesn't seem to happen every time but it does happen a lot. I compared the source code, and this comes from libglusterfs/src/common-utils.c The glusterfs 7.9 version has the same behavior, but without the "log and ignore". I plan to put a patch for now -- since time is running out -- to inhibit this warning as it is alarming QE and potentially customers later. Is there any reason I should not do this? Another option would be to supply a whole server list but it's too late - the clock ran out for that change until the next release of our software. Here is my fstab line on a head node that uses highly available IPs to connect to the gluster servers instead of their main IP. pupusa:/var/log/glusterfs # cat /etc/fstab | grep glusterfs 172.23.255.201:/cm_shared /opt/clmgr/shared_storage glusterfs defaults,_netdev,acl,selinux 0 0 172.23.255.201:/cm_logs /opt/clmgr/cm_logs glusterfs defaults,_netdev,acl,selinux 0 0 172.23.255.201:/cm_obj_sharded /opt/clmgr/cm_obj_sharded glusterfs defaults,_netdev,acl,selinux 0 0 I understand that maybe would be preferred if I used a server list (which could be 24 servers on our biggest system) and if you all say I should do it that way, I can change it for the next release cycle that comes out in like 8 months. I'm hoping we're OK with the IP alias and I can inhibit the warning in the context of glusterfs 9.3 but if that scares anybody let me know!! Thank you all !!!! Erik ------- 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
