From mboxrd@z Thu Jan 1 00:00:00 1970 From: Josh Durgin Subject: Re: PG recovery reservation state chart Date: Tue, 02 Oct 2012 15:00:55 -0700 Message-ID: <506B6417.9020009@inktank.com> References: <20121002194858.GC8206@splice> <20121002204249.GF8206@splice> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pb0-f46.google.com ([209.85.160.46]:56419 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753585Ab2JBWA6 (ORCPT ); Tue, 2 Oct 2012 18:00:58 -0400 Received: by pbbrr4 with SMTP id rr4so9188010pbb.19 for ; Tue, 02 Oct 2012 15:00:57 -0700 (PDT) In-Reply-To: <20121002204249.GF8206@splice> Sender: ceph-devel-owner@vger.kernel.org List-ID: To: Mike Ryan Cc: Tommi Virtanen , ceph-devel@vger.kernel.org On 10/02/2012 01:42 PM, Mike Ryan wrote: > On Tue, Oct 02, 2012 at 01:35:34PM -0700, Tommi Virtanen wrote: >> On Tue, Oct 2, 2012 at 12:48 PM, Mike Ryan wrote: >>> Tried sending this earlier but it seems the list doesn't like PNGs. >>> dotty or dot -Tpng will make short work of the .dot file I've attached. >> >> vger discards messages with attachments. It's old school mailing list >> software. It's also used by many old school communities, that consider >> this a valuable anti-spam tactic, so they're not interested in >> changing it. > > I figured as much. It would have been nice to receive a notification > that it was dropped rather than having it silently fall on the floor, > especially since a copy of the message is not sent to the sender upon > list acceptance. c'est la vie > >> Once this becomes less a design hypothetical and more a description of >> how the code works, please please please put the dot in doc/dev/ > > This is unnecessary, as the doc scripts will automatically generate a > full peering state chart (of which this is just a sub state). Major > kudos to Sam Just for making that happen! It'd be good to update doc/dev/osd_internals with a description of the reservations though, maybe expanding doc/dev/osd_internals/backfill_reservation. One other thing I'd like to see made explicit: How does this handle upgrades? i.e., what will happen when some OSDs have this reservation mechanism and some do not?