<div dir="ltr">Hi.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Welcome to the club.<br>
<div class="im"><br>
</div></blockquote><div><br>Thanks, wish it filled nice to be welcomed :).<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Do you mean that you loose the whole file or just the content of the file?<br>
Somehow lately the whole AFR functionality is borked for me. I tried to reduce everything to the minimum (no performance translators or anything other not needed) and still I am loosing data. Restarting server and client can lead to total loss of content for some files in my case.<br>
</blockquote><div><br>I don't really know, because the total difference in used space between server 1 and server 2, sometimes reaches more then 50%!<br><br>Now, I noticed that this might be related to case when there is no space left on the mount point, meaning that GlusterFS is unable to write for some time.<br>
<br>Things go downhill from there, and even if the space freed, there is a large difference between server one and server two. Running ls -lR doesn't help at all. The only way to get things back to normal, seems so far to erase all the data, and restart all the servers + client.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
> 3) Possible memory leak<br>
><br>
Could you provide valgrind dumps showing where the leaks are occurring?<br>
<font color="#888888"></font></blockquote><div><br>Good idea - will do. Though I think it mostly related to read-ahead and io threads translators. When I removed the and only left write-behind and cache, things seems to have improved.<br>
<br>Regards.<br></div></div></div>