Hi Barak,
My replies inline.
On Thu, Nov 21, 2019 at 6:34 PM Barak Sason Rofman
wrote:
> Hello Gluster community,
>
> My name is Barak and I’ve joined RH gluster development in August.
> Shortly after my arrival, I’ve identified a potential problem with
> gluster’s logging mechanism and I’d
On Fri, Nov 22, 2019 at 11:45 AM Barak Sason Rofman
wrote:
> Thank you for your input Atin and Xie Changlong.
>
> Regarding log ordering - my initial thought was to do it offline using a
> dedicated too. Should be straight forward, as the logs have time stamp
> composed of seconds and
在 2019/11/22 17:43, Barak Sason Rofman 写道:
Thank you for your input Atin and Xie Changlong.
Regarding log ordering - my initial thought was to do it offline using
a dedicated too. Should be straight forward, as the logs have time
stamp composed of seconds and microseconds, so ordering them
Thank you for your input Atin and Xie Changlong.
Regarding log ordering - my initial thought was to do it offline using a
dedicated too. Should be straight forward, as the logs have time stamp
composed of seconds and microseconds, so ordering them using this value is
definitely possible.
This is
在 2019/11/21 21:04, Barak Sason Rofman 写道:
I see two design / implementation problems with that mechanism:
1.
The mutex that guards the log file is likely under constant
contention.
2.
The fact that each worker thread perform the IO by himself, thus
slowing his "real" work.
This is definitely a good start. In fact the experiment you have done which
indicates a 20% improvement of run time perf with out logger does put this
work for a ‘worth a try’ category for sure. The only thing we need to be
mindful here is the ordering of the logs to be provided, either through a
Hello Gluster community,
My name is Barak and I’ve joined RH gluster development in August.
Shortly after my arrival, I’ve identified a potential problem with
gluster’s logging mechanism and I’d like to bring the matter up for
discussion.
The general concept of the current mechanism is that
