> For comparison, below is the output of getfattr on each brick and > on a client, starting with the brick causing trouble (gluster-0-1): > > ------------ > gluster-0-1 > ------------ > [root@nas-0-1 mseas-data-0-1]# getfattr -d -e hex -m . . > # file: . > trusted.gfid=0x00000000000000000000000000000001 > trusted.glusterfs.dht=0x00000001000000000000000055555554 > trusted.glusterfs.volume-id=0xeccc3a90212d4563ae8d10a77758738d > > ------------ > gluster-data > ------------ > [root@mseas-data data]# getfattr -d -e hex -m . . > # file: . > trusted.gfid=0x00000000000000000000000000000001 > trusted.glusterfs.dht=0x000000010000000055555555aaaaaaa9 > trusted.glusterfs.volume-id=0xeccc3a90212d4563ae8d10a77758738d > > ------------ > gluster-0-0 > ------------ > # file: . > trusted.gfid=0x00000000000000000000000000000001 > trusted.glusterfs.dht=0x0000000100000000aaaaaaaaffffffff > trusted.glusterfs.volume-id=0xeccc3a90212d4563ae8d10a77758738d That looks pretty reasonable - an approximately even split of the DHT hash range across the three bricks, which should result in files being evenly allocated between them. Also, you said that there was a directory where you *didn't* see the problem? Could you run the same command there for comparison? _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-users
