On 02/15/2017 08:51 PM, Atin Mukherjee wrote:
On Thu, 16 Feb 2017 at 04:09, Jeff Darcy <jda...@redhat.com
<mailto:jda...@redhat.com>> wrote:
One of the issues that has come up with multiplexing is that all of
the bricks in a process end up sharing a single log file. The
reaction from both of the people who have mentioned this is that we
should find a way to give each brick its own log even when they're
in the same process, and make sure gf_log etc. are able to direct
messages to the correct one. I can think of ways to do this, but it
doesn't seem optimal to me. It will certainly use up a lot of file
descriptors. I think it will use more memory. And then there's the
issue of whether this would really be better for debugging. Often
it's necessary to look at multiple brick logs while trying to
diagnose this problem, so it's actually kind of handy to have them
all in one file. Which would you rather do?
(a) Weave together entries in multiple logs, either via a script or
in your head?
(b) Split or filter entries in a single log, according to which
brick they're from?
To me, (b) seems like a much more tractable problem. I'd say that
what we need is not multiple logs, but *marking of entries* so that
everything pertaining to one brick can easily be found. One way to
do this would be to modify volgen so that a brick ID (not name
because that's a path and hence too long) is appended/prepended to
the name of every translator in the brick. Grep for that brick ID,
and voila! You now have all log messages for that brick and no
other. A variant of this would be to leave the names alone and
modify gf_log so that it adds the brick ID automagically (based on a
thread-local variable similar to THIS). Same effect, other than
making translator names longer, so I'd kind of prefer this
approach. Before I start writing the code, does anybody else have
any opinions, preferences, or alternatives I haven't mentioned yet?
(b) is better. Considering centralized logging or log file redirection
etc, (a) becomes unnatural and unwieldy, (b) is better.
I like this idea. +1
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org <mailto:Gluster-devel@gluster.org>
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
- Atin (atinm)
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://lists.gluster.org/mailman/listinfo/gluster-devel
