Thanks Greg. ---------------------------------------- > Date: Tue, 27 Oct 2015 12:47:34 -0700 > Subject: Re: PG: all requests stuck when acting set < min_size > From: gfarnum@xxxxxxxxxx > To: yguang11@xxxxxxxxxxx > CC: ceph-devel@xxxxxxxxxxxxxxx > > On Tue, Oct 27, 2015 at 11:47 AM, GuangYang <yguang11@xxxxxxxxxxx> wrote: >> Hi there, >> Is there any reason we stuck read only requests as well for a PG when the acting set size is less than min_size? > > A few. > The most important reason: PGs don't have any concept of a read-only > mode in the code. They are "active" or not, and an active PG handles > writes. (The full flags and other things which block writes but allow > reads are at the OSD level, not the PG level, and are handled when ops > come in before they reach the PG.) Allowing read requests against a PG > to complete even when we aren't taking writes on a per-PG level would > take some doing. [yguang] Yeah that is what I thought as well, I didn't see a read-only PG state, they are either active or inactive (incomplete). > Also: it would be weird from several different levels. We'd need to > keep track of client streams because we wouldn't want to let through a > read that is ordered after a write. How would we handle the memory > pressure implied by that? [yguang] I am not aware of this part, could you elaborate a little bit? While I can imagine it being useful for some > stuff like RGW reads, in general making data available for read but > not write is a pretty complicated thing to explain to users — how do > we expose that in a useful way? [yguang] The motivation is to improve availability upon failures (yay we are using radosgw:), and some use cases of object storage like S3, most commonly object are written once, read many, and this could help with the availability. > -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
