Apparently your server-side storage got tainted and there are still
files in those directories on your bricks. AFAIK, you can remove those
files directly from the server side as long as they don't show up on the
client side.
I had the same thing happen to me with 2.0.2. When I upgraded to 2.0.7,
those files really caused confusion as it created duplicate filenames.
The way I resolved it was to:
mv foo1 foo1~
cp -a foo1~ foo1
rm -rf foo1~
Then I went to each brick and rm -rf {brick directory}/foo1~
This created a clean foo1 with no corrupted backend storage.
On 11/6/2009 5:12 AM, Abhishek Singh wrote:
> Hi ,
>
> I have setup of four glusterFS server and one client. I am facing issue
> during removing older directories after adding 4th node in cluster.
>
> I am getting **rm: cannot remove directory** while doing **rm -rf dirname**.
> I
> started glusterfs client in debug mode and found following entries in log
> file.
>
> [2009-11-06 13:09:11] D [fuse-bridge.c:921:fuse_unlink_cbk] glusterfs-fuse:
> 84: RMDIR() /dir1/20091001010001 => -1 (Directory not empty)
> [2009-11-06 13:09:11] D [fuse-bridge.c:921:fuse_unlink_cbk] glusterfs-fuse:
> 87: RMDIR() /dir1/20091002010002 => -1 (Directory not empty)
> [2009-11-06 13:09:11] D [fuse-bridge.c:921:fuse_unlink_cbk] glusterfs-fuse:
> 90: RMDIR() /dir1/20091003010002 => -1 (Directory not empty)
> [2009-11-06 13:19:03] D [fuse-bridge.c:921:fuse_unlink_cbk] glusterfs-fuse:
> 19076: RMDIR() /dir1/20090921010002 => -1 (Directory not empty)
> [2009-11-06 13:19:29] D [fuse-bridge.c:921:fuse_unlink_cbk] glusterfs-fuse:
> 19096: RMDIR() /dir1/20090921010002 => -1 (Directory not empty)
>
> Can anybody help me to resolve this issue?
>
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://gluster.org/cgi-bin/mailman/listinfo/gluster-users
>
