<div dir="ltr"><div>Also directories got removed. I did a really bad job in that script, wrong sed and path was not truncated and replaced with the fuse mountpoint...</div><div>Yes I can move to 3.3.2qa3. At the moment I have gluster installed as per the semiosis repository. What is the best way for me to move to this other version (I think that I have to build it from source?)?</div>

<div>¬†</div><div>Thanks and best regards,</div><div>Stefano</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 2, 2013 at 4:15 PM, Vijay Bellur <span dir="ltr">&lt;<a href="mailto:vbellur@redhat.com" target="_blank">vbellur@redhat.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/02/2013 11:35 AM, Stefano Sinigardi wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Dear Vijay,<br>
the filesystem is ext4, on a GPT structured disk, formatted by Ubuntu 12.10.<br>
</blockquote>
<br></div>
A combination of ext4 on certain kernels and glusterfs has had its share of problems (<a href="https://bugzilla.redhat.com/show_bug.cgi?id=838784" target="_blank">https://bugzilla.redhat.com/<u></u>show_bug.cgi?id=838784</a>) for readdir workloads. I am not sure if the Ubuntu 12.10 kernel is affected by this bug as well. GlusterFS 3.3.2 has an improvement which will address this problem seen with ext4.<div>

<div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
The rebalance I did was with the command<br>
gluster volume rebalance data start<br>
but in the log it got stuck on a file that I cannot remember (was a<br>
small working .cpp file, saying that it was going to be moved to an much<br>
more occupied replica, and it repeated this message until writing a log<br>
that was a few GB).<br>
Then I stopped it and restarted with<br>
gluster volume rebalance data start force<br>
in order to get rid of this problems about files going to bricks already<br>
highly occupied.<br>
Because I was almost stuck, remembering that a rebalance solved another<br>
problem I had as a miracle, I retried it, but got stuck in a<br>
.dropbox-cache folder. That is not a very important folder, so I thought<br>
I could remove it. I launched a script to find all the files looking at<br>
all the bricks but removing them from the fuse mountpoint. I don&#39;t know<br>
what went wrong (the script is very simple, the problem maybe was that<br>
it was 4 am in the night) but the fact is that files got removed calling<br>
rm at the bricks mountpoints, not the fuse one. So I think that now I&#39;m<br>
in a even worse situation that before. I just stopped working on it,<br>
asking for some time from my colleagues (at least data is still there,<br>
on the bricks, just sparse on all of them) in order to think well about<br>
how to proceed (maybe destroying it and rebuilding it, but it will be<br>
very time consuming as I don&#39;t have so much free space elsewere to save<br>
everything, also it&#39;s very difficult to save from the fuse mountpoint as<br>
it&#39;s not listing all the files)<br>
</blockquote>
<br></div></div>
Were only files removed from the brick mountpoints or did directories get removed too? ¬†Would it be possible for you to move to 3.3.2qa3 and check if ls does list all files present in the bricks? Note that, qa3 is not yet GA and might see a few fixes before it becomes so.<br>


<br>
Regards,<br>
Vijay<br>
<br>
<br>
</blockquote></div><br></div>