On Wednesday, April 11, 2012 at 3:18 PM, Noah Watkins wrote: > One could pair the pointer with a magic value in a separate structure, but even libc doesn't go to these lengths to protect users... At that point we'd run a pretty high risk of segfaulting when trying to deref and look at the magic value anyway. Nothing useful we can do here, I think. :/ On Wednesday, April 11, 2012 at 3:29 PM, Noah Watkins wrote: > > On Apr 11, 2012, at 11:32 AM, Greg Farnum wrote: > > > On Wednesday, April 11, 2012 at 11:25 AM, Noah Watkins wrote: > > > > > > On Apr 11, 2012, at 11:22 AM, Greg Farnum wrote: > > > > > > > On Wednesday, April 11, 2012 at 11:12 AM, Noah Watkins wrote: > > > > > Hi all, > > > > > > > > > > -Noah > > > > I'm not sure where the "-1004" came from, > > > > > > > > > > > > ceph_mount(..) seems to return some random error codes (-1000, 1001) already :) > > > > <grumble> legacy undocumented grr </grumble> > > Let's try to use standard error codes where available, and (if we have to create our own) document any new ones with user-accessible names and explanations. I don't know which one is "best" but I see a lot of applicable choices when scanning errno-base et al. > > > > If I'm choosing from from errno-base I might go with > > #define ENXIO 6 /* No such device or address */ > > It's used: > > osd/OSD.cc (http://OSD.cc) > void OSD::handle_misdirected_op(PG *pg, OpRequest *op) > … > reply_op_error(op, -ENXIO) > > I'm wondering if you happen to know if this will be propagated back to the client? I'd be nice to have an exclusive not-mounted condition on the client side. > > -Noah Unfortunately it is. (I just grepped and see it's returned by both the MDS and the OSD, but it's not in Objecter et al so it's not filtered out anywhere.) ENODEV isn't returned from anything; do you think that makes sense? -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
