> However, other times, the "rm" doesn't report an error, but the file remains > visible via "ls" and the rmdir fails. when this case happens does the ls show a linkto file or the original data file. > When I looked at the system calls via ktrace (I'm guessing similar to strace > under Linux?), the unlink syscalls always succeed (reply 0) and the getdirentries() > find entries in the directories. (I'd guess that means that the "lookup" done > in the "unlink" succeeds?) >From the ktrace, can you check which syscall failed when the rm on a file fails. Also can you share the ktrace log files if you have them? > Sorry this isn't particularily useful, but it's all I have, rick The system on which you are getting the errors, is it a vm which I can access? So that I can try few more extra tests? > ----- Original Message ----- > From: "Rick Macklem" <rmacklem@xxxxxxxxxxx> > To: "Sakshi Bansal" <sabansal@xxxxxxxxxx> > Cc: "Raghavendra Gowdappa" <rgowdapp@xxxxxxxxxx>, "Gluster Devel" > <gluster-devel@xxxxxxxxxxx> > Sent: Thursday, January 21, 2016 10:03:37 AM > Subject: Re: rm -r problem on FreeBSD port > > Sakshi Bansal wrote: > > The directory deletion is failing with ENOTEMPTY since not all the files > > inside it have been deleted. Looks like lookup is not listing all the > > files. > > It is possible that cluster.lookup-optimize could be the culprit here. When > > did you turn this option 'on'? Was it during the untaring of the source > > tree? > > Also once this option if turned 'off', explicitly doing an ls on the > > problematic files still throw error? > > > Good suggestion. I had disabled it but after I had created the tree > (unrolled the tarball and created the directory tree that the build goes in). > > I ran a test where I disabled all three of: > performance,readdir-ahead > cluster.lookup-optimize > cluster.readdir-optimize > right after I created the volume with 2 bricks. > > Then I ran a test and everything worked. I didn't get any directory with > files > missing when doing an "ls" and the "rm -r" worked too. > So, it looks like it is one or more of these settings and they have to be > disabled when the files/directories are created to fix the problem. > > It will take a while, but I will run tests with them individually disabled > to see which one(s) need to be disabled. Once I know that I'll email and > try to get the other information you requested to see if we can isolate the > problem further. > > Thanks, I feel this is progress, rick > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
