On Wed, Jun 21, 2017 at 7:46 AM, Daniel Gryniewicz <dang@xxxxxxxxxx> wrote: > On 06/21/2017 10:04 AM, Matt Benjamin wrote: >> >> Hi, >> >> Looks very coherent. >> >> My main question is about... >> >> ----- Original Message ----- >>> >>> From: "Jiaying Ren" <mikulely@xxxxxxxxx> >>> To: "Yehuda Sadeh-Weinraub" <ysadehwe@xxxxxxxxxx> >>> Cc: "ceph-devel" <ceph-devel@xxxxxxxxxxxxxxx> >>> Sent: Wednesday, June 21, 2017 7:39:24 AM >>> Subject: RGW: Implement S3 storage class feature >>> >> >>> >>> * Todo List >>> >>> + the head of rgw-object should only contains the metadata of >>> rgw-object,the first chunk of rgw-object data should be stored in >>> the same pool as the tail of rgw-object >> >> >> Is this always desirable? >> > > Well, unless the head pool happens to have the correct storage class, it's > necessary. And I'd guess that verification of this is complicated, although > maybe not. > > Maybe we can use the head pool if it has >= the correct storage class? > My original thinking was that when we reassign an object to a new placement, we only touch its tail which is incompatible with that. However, thinking about it some more I don't see why we need to have this limitation, so it's probably possible to keep the data in the head in one case, and modify the object and have the data in the tail (object's head will need to be rewritten anyway because we modify the manifest). I think that the decision whether we keep data in the head could be a property of the zone. In any case, once an object is created changing this property will only affect newly created objects, and old objects could still be read correctly. Having data in the head is an optimization that supposedly reduces small objects latency, and I still think it's useful in a mixed pools situation. The thought is that the bulk of the data will be at the tail anyway. However, we recently changed the default head size from 512k to 4M, so this might not be true any more. Anyhow, I favour having this as a configurable (which should be simple to add). Yehuda -- 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
