Dear All:
I have a problem that after I mount a volume, any I/O to it hangs. This is usually a symptom of volume that is not started, as I heard. So, I checked, and when I run "gluster volume info", it outputs "Status: Created". I am trying to figure out what is going on, but so far only found that the volumes are kept by glusterd in a mysterious list. Not sure how it's updated. The question is, is it ok for the status not to be "Started" for volumes under the management of HekaFS (my version is new enough to launch a separate instance of glusterfsd). And if not, what can be done to fix it?
Thanks in advance, -- Pete
On Fri, 4 Nov 2011 17:39:14 -0600 Pete Zaitcev zaitcev@redhat.com wrote:
I have a problem that after I mount a volume, any I/O to it hangs. This is usually a symptom of volume that is not started, as I heard. So, I checked, and when I run "gluster volume info", it outputs "Status: Created". I am trying to figure out what is going on, but so far only found that the volumes are kept by glusterd in a mysterious list. Not sure how it's updated. The question is, is it ok for the status not to be "Started" for volumes under the management of HekaFS (my version is new enough to launch a separate instance of glusterfsd). And if not, what can be done to fix it?
Yes, it's normal for the gluster/glusterd status of a HekaFS volume to remain at "Created" even after it has been started via hfs_start_volume (or the web-UI equivalent). It only moves to "Started" when the daemons are started by glusterd, and that lacks the intelligence to deal with HekaFS's multi-tenant volfiles. In general, one should *never* use the GlusterFS CLI to manage or modify HekaFS volumes. That's a bit like using hdparm to change disk parameters while a filesystem is running on it.
In the not-too-distant future this should all change, and the things HekaFS needs to do for multi-tenancy or other features will be completely integrated into the GlusterFS management infrastructure. That won't happen for some weeks to months, though.
On Mon, 7 Nov 2011 08:14:13 -0500 Jeff Darcy jdarcy@redhat.com wrote:
Yes, it's normal for the gluster/glusterd status of a HekaFS volume to remain at "Created" even after it has been started via hfs_start_volume (or the web-UI equivalent).
Thanks, Jeff. So, the problem is that the I/O hangs like it would do on normal glusterfs volumes if they're not started. I'm going to try and figure it out.
-- Pete
On Mon, 7 Nov 2011 08:14:13 -0500 Jeff Darcy jdarcy@redhat.com wrote:
I have a problem that after I mount a volume, any I/O to it hangs.
Yes, it's normal for the gluster/glusterd status of a HekaFS volume to remain at "Created" even after it has been started via hfs_start_volume []
Tangentially, it looks that I may have configured something wrong. Since I only have one user, I did this: hfs_add_tenant zaitcev volpass 531 531 531 531 But the code in rbmap.c seems to assume that I need something like hfs_add_tenant zaitcev volpass 531 531 531 532 or else uid_next is always outside the map. While it's easy to adjust, I am primarily curious about the hang. Trying to figure out if the bad return from map() can trigger the hang, or it happens for other reason.
-- P
cloudfs-devel@lists.fedorahosted.org