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

[Rick Macklem]

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 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
> > > 
> > 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>