[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ceph-devel
Subject:    Re: [Bug Report] Running git-clone on ceph get "File exists" errors
From:       Sage Weil <sage () newdream ! net>
Date:       2010-05-21 15:57:41
Message-ID: Pine.LNX.4.64.1005210851180.11676 () cobra ! newdream ! net
[Download RAW message or body]

On Fri, 21 May 2010, Henry C Chang wrote:
> These errors are similar to the issue mentioned in
> http://ceph.newdream.net/git/?p=ceph-client-standalone.git;a=commit;h=f131f56ea2a09edc5de227975ef7b57ba1592880.
>  But, it does not work for my case.
> 
> So, I traced the client and mds logs. It looks like
> ceph_mdsc_do_request() does not handle ERESTARTSYS properly.
> The logs show that the file creation request had been sent to MDS, and
> MDS did complete the request.
> However, before the reply has been received, the request on the client
> side was aborted due to some interrupt.
> VFS got the ERESTARTSYS error and tried to create the file again.
> Since MDS has already created the file, "File exists" errors were returned.
> 
> Then, I replaced "wait_for_completion_interruptible" with
> "wait_for_completion" in ceph_mdsc_do_request().
> The above errors were gone, but I don't feel it is a right way to fix
> it. Any ideas?

Hmm.  The problem is that ideally we want to be able to control-c an 
operation if the mds is slow or hung.  However, hitting control-c triggers 
an ERESTARTSYS, same as a bunch of other signals that come up.

If there is a way for the client to tell that it is retrying the _same_ 
vfs op and somehow match that up with the pending request, then we could 
do that, but I'm skeptical that would work (or be very pretty).  It may be 
we need to drop the ability to control-c on a slow/hung operation.  :/

There is probably a way to tell which signal is pending when we get 
ERESTARTSYS?  I wonder what NFS does in this case?

I created http://tracker.newdream.net/issues/141

sage
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]