[GEDI] Unexpected libgfapi behaviour

Denis Chaplygin dchaplyg at redhat.com
Mon Oct 30 13:58:48 UTC 2017


On Mon, Oct 30, 2017 at 2:14 PM, Niels de Vos <ndevos at redhat.com> wrote:

> The best logging you can get is when you use the glfs_set_logging()
> call:
>   https://github.com/gluster/glusterfs/blob/release-3.12/
> api/src/glfs.h#L199
> Make sure that the process can create the logfile. By default the
> log-level is set to INFO(7), setting it to DEBUG(8) or TRACE(9) might be

Ok, it will take some time to implement...

> The connection to glusterd is only for the management part. Once
> glfs_init() is called, the volume layout is fetched from glusterd, and
> based on those details, the connections to the bricks are made. You can
> check the logs from the bricks to see if connections go established.
> Capturing a tcpdump on the system where the gfapi application is running
> and loading it in wireshark can show more whats happening on the network
> side (wireshark knows most of the Gluster protocol).
Looks like it loads volinfo and everything stops here. I attached my dump
file, so you make take a look on it if you like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/integration/attachments/20171030/7aede653/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gluster
Type: application/octet-stream
Size: 19003 bytes
Desc: not available
URL: <http://lists.gluster.org/pipermail/integration/attachments/20171030/7aede653/attachment-0001.obj>

More information about the integration mailing list