Krish,
Thanks for your help ,but my circumstance is that the "tursted.glusterfs.dht"
xattr is set just without the mount process running. I know that the mount
process can do the hash-range-assign job , but in my case , the mount
process at the client side is not being run when I do the "volume start"
commond at the server side , and the "tursted.glusterfs.dht" xattr can be
set correctly too. So I guess that there must be some other process at the
server side did the hash-range-assign job, I just want to find out which
process did it. Can you give me some information about this, thanks!
Thanks again,
Xinguo
At 2014-01-21 01:18:37,"Krishnan Parthasarathi" <address@hidden> wrote:
Xinguo,
You should be attaching gdb to the mount process. The process serves
filesystem requests on the mount point. This process has the mount point
(directory) in its command line arguments. This should help you find out
the pid of the process using ps(1).
Hope that helps,
krish
----- Original Message -----
Hello,
In glusterfs server side , when we do the "volume start" commond , every
brick's root directory will be set the "tursted.glusterfs.dht" xattr and
will be assigned a hash-range , as soon as the commond returned
successfully
. we know that the function "dht_selfheal_layout_new_directory()" do the
hash-range assign work , but when I make a breakpoint at function
"dht_selfheal_layout_new_directory()" in the attached process "glusterd"
before doing the "volume start" commond , the "glusterd" process won't
stop
at the breakpoint and the "tursted.glusterfs.dht" xattr of every brick's
root directory still be set successfully . Why ? Did I attached the wrong
process ? What shoud I do to let the hash-range assigning work stop so I
can
follow the assigning work step by step ?
hope to get help,
thanks,
Xinguo
_______________________________________________
Gluster-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/gluster-devel