(resending to get through the list) My main concern is that the whole notion of hint needs to be abstracted. Instead of having a specific op for allocation hints we should have a generic hint operation that would contain a hint type in it. That hint will then be parsed within the various osd components, and will be used if identified and if needed. Then you'd be able to add various hints without needing to change the protocol itself. Not sure if the operation itself needs to have a "write" flag set on it, as hints may apply to read operations too (e.g., a hint to prefetch data read). We may want to create two different ops, one for read and one for write. I think that a first step would be to modify the current op and add a "hint type" string at the data portion, and an optional bufferlist for data. The size params need to be generic and not specific (param1, param2, ...). The reasoning behind that is that at one point we may have different backbends plugging into the osd externally. Providing a proper osd backbend sdk might be another step. So we'd want this to be as abstract as possible. These hints could be sent blindly without the osd needing to understand their meaning, leaving it to the backbend to interpret. Yehuda On Sunday, February 23, 2014, Sage Weil <sage@xxxxxxxxxxx> wrote: > > Hey Sam, Yehuda, > > Can you take a final look at https://github.com/ceph/ceph/pull/1284? > > Yehuda, you mentioned wanting to make the hint op as general as possible. > This bit is only addressing the allocation piece, and there is room in the > args struct to add additional fields (so far 0 means 'not > specified/undefined'), but I'm not sure if that captures your concerns. > > Thanks! > sage > > -- 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
