Krishnan Parthasarathi wrote:
Xinguo,

dht translator is responsible for the "trusted.glusterfs.dht.*" extended
attributes. The code for this is present at xlators/cluster/dht/src relative
to the root of the code repo.

Did you perform any rebalance or remove-brick operation after starting
the brick and before writing any data on the volume via a mount?
These are other processes that include dht translator in their runtime.
I suspect gluster-nfs process does also load the dht which will be started
at the time of volume start.

thanks,
Krish



----- Original Message -----
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" <kpart...@redhat.com> 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
  Gluster-devel@nongnu.org
  https://lists.nongnu.org/mailman/listinfo/gluster-devel

_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel


_______________________________________________
Gluster-devel mailing list
Gluster-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/gluster-devel

Reply via email to