<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Mar 2019 at 20:07, Sankarshan Mukhopadhyay <<a href="mailto:sankarshan.mukhopadhyay@gmail.com">sankarshan.mukhopadhyay@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 20, 2019 at 10:00 AM Atin Mukherjee <<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@redhat.com</a>> wrote:<br>
><br>
> From glusterd perspective couple of enhancements I'd propose to be added (a) to capture get-state dump and make it part of sosreport . Off late, we have seen get-state dump has been very helpful in debugging few cases apart from it's original purpose of providing source of cluster/volume information for tendrl (b) capture glusterd statedump<br>
><br>
<br>
How large can these payloads be? One of the challenges I've heard is<br>
that users are often challenged when attempting to push large ( > 5GB)<br>
payloads making the total size of the sos archive fairly big.</blockquote><div dir="auto"><br></div><div dir="auto">get-state and glusterd statedump are just mere text files of few KBs . Your example is referring to brick statedump file having many multiplexed bricks in a single process.</div><div dir="auto"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org" target="_blank">Gluster-devel@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/gluster-devel</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--Atin</div>