I wrote: > Sakshi Bansal wrote: > > > 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. > > > It sometimes shows a single entry and sometimes two entries, but they are > always for a file and not a "linkto". (Always have the mode and size of the > file and never 0s for mode or size. Basically the two lines are identical.) > You sometimes get one vs two for "ls -l" typed twice is a row. > To clarify, the above is what "ls -l" replies when done on the fuse mount. When I look on the underlying bricks, I see the file on one brick and a "linkto" with the same name on the other brick. rick > rick > > > > > > 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 > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
