On Fri, Jan 22, 2010 at 3:07 PM, Sage Weil <s...@newdream.net> wrote: > > Are there other places that should be handling ERESTARTSYS?
Anywhere we have interruptible wait are the obvious places. There are a few places of those. I guess that we may get that when calling other kernel internal functions. I guess there are other places where we can hit it (e.g., call to kernel_recvmsg). > > There's commit ed03dec7, btw, which looks a lot like the below. Yeah.. sadly (or luckily) I'm on a different branch. This would have solved it. > > Also, thinking about it more, I think we may be able to make things > interruptible and still process enough of the reply to keep things in > sync. The ceph_fill_trace does two different things: it processes the > caps and updated inode info, which we can do even if it's interrupted, and > it handles any namespace changes in the dcache, which it can't because we > won't hold the dir i_mutex any more. I think we'll just need to mark a > request as aborted so that function knows the dir mutex is no longer held, > and skips the appropriate bits. We should probably just be doing our best effort with what we got. This specific bug wouldn't have happened had we updated the caps. Not sure about namespace changes, maybe being able to mark the dir invalid without needing to hold the i_mutex? > > What exactly should happen in that case for things like rename is an open > question... probably nothing? Presumably the request dropped the > appropriate leases, so any subsequent operations will need to relookup the > affected dentries? Yeah, probably. I don't think that such a scenario where the mds and the client don't agree on a file's name is possible, since the client dropped the relevant lease for the rename. However we shouldn't rely on the specific operation implementation, and we should make sure that we can either mark the directory or the relevant dentries as invalid. Yehuda ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Ceph-devel mailing list Ceph-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ceph-devel
