> Using GFID does not work for d_off. The GFID represents and inode, and a > d_off represents a directory entry. Therefore using GFID as an alternative > to d_off breaks down when you have hardlinks for the same inode in a single > directory. Good point. So what *can* we do locally on a brick to create a truncated d_off (e.g. 48 bits) that's more collision-free than random hashes and likely to be consistent across replicas? I've thought of a few such schemes, but haven't worked out all of the details for any of them yet. Maybe someone else will be able to come up with something that cuts this problem down to a manageable size. _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
