Hello All, I have seen what appears to be the same problem when a user tried to change the ownership of some files. The client log file entries were like this: [2011-01-05 17:10:02.222293] W [fuse-bridge.c:648:fuse_setattr_cbk] glusterfs-fuse: 16210806: SETATTR() /users/rle/INTERIM/INTERIM_2003_VOR850.nc => -1 (Invalid argument) The error reported on the command line was "permission denied" I am told, not "invalid argument" as with the file deletion problem. Unfortunately I didn't get a chance set the log level to TRACE because the user in question went to an NFS client to change the ownership before telling me there had been a problem. However this might make it easier to reproduce the problem, now that we know that it isn't restricted to file deletion. -Dan. - On 01/06/2011 09:07 AM, Thai. Ngo Bao wrote: > Dear All, > > I'd like to confirm that I am having the same problem. I am using glusterfs 3.1.1. > > I did set volume diagnostics.client-log-level to TRACE, please see the attached file for further information. > > Thanks for your support. > > ~Thai > -----Original Message----- > From: gluster-users-bounces at gluster.org [mailto:gluster-users-bounces at gluster.org] On Behalf Of Vijay Bellur > Sent: Wednesday, January 05, 2011 1:30 AM > To: Dan Bretherton > Cc: gluster-users > Subject: Re: Invalid argument on delete with GlusterFS 3.1.1 client > > On Tuesday 04 January 2011 11:21 PM, Dan Bretherton wrote: >> Hello Vijay, >> There is nothing except routine "accepted client" messages in the >> brick log files on the servers, and I can't see anything relevant in >> the /var/log/messages files. On the client the only messages relating >> to this problem were included in my original mailing list message. Are >> there some other log files I should be looking at? I don't know how >> to recreate this problem I'm afraid - it's just a case of waiting >> until it crops up again. When it does I will try to persuade the >> users to leave the files in place while I investigate further. When >> the time comes what should I look for? >> > When it happens again, please set the glusterfs client log level to > TRACE through > > #gluster volume set<volname> diagnostics.client-log-level TRACE, > perform the delete operation on such files and send across the client > log file to us. > > You can revert back the log level to INFO after you are done with this. > > Thanks, > Vijay > > > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users