On Mon, Dec 9, 2013 at 4:11 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: > On 12/06/2013 06:24 PM, Gregory Farnum wrote: >> >> On Fri, Dec 6, 2013 at 6:16 PM, Josh Durgin <josh.durgin@xxxxxxxxxxx> >> wrote: >>> Don't bother trying to stop ENOSPC on the client side, since it'd need >>> some >>> restructuring in the kernel side and would be prone to screwing up >>> write ordering. >>> >>> Instead drop writes on the osd side when they have a map marked full, >>> and have clients resend all writes when a map goes transitions from >>> full -> nonfull. The userspace side is >>> https://github.com/ceph/ceph/pull/914 >> >> >> Do previous client implementations already satisfy that requirement? >> We can't drop requests if older clients expect a response... > > > No, previous clients do not do this. For old rbd clients, this turns a > potential corruption into a hang, which is a good trade-off imo. > > For userspace clients, this only happens when the osd gets the FULL map > first, and rejects a write in flight before the client got a FULL map. > > The kernel client already rejects writes at the fs layer when the FULL > flag is set, so kcephfs will only be affected when it hits this race as > well. Hrm, do we have mechanisms in the kernel for re-sending ops that are waiting? Hanging instead of corrupting doesn't help us much if we have no way to get the proper state ondisk. -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
