[Gluster-devel] rm -r problem on FreeBSD port

[Sakshi Bansal]

> 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 at uoguelph.ca>
> To: "Sakshi Bansal" <sabansal at redhat.com>
> Cc: "Raghavendra Gowdappa" <rgowdapp at redhat.com>, "Gluster Devel"
> <gluster-devel at gluster.org>
> Sent: Thursday, January 21, 2016 10:03:37 AM
> Subject: Re: [Gluster-devel] 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
>