On Wed, Jul 27, 2011 at 7:39 AM, huang jun <hjwsm1989@xxxxxxxxx> wrote: > Hello > I have two questions about OSD. > 1) From the current READ ops, whether the OSD can provide the > readahead strategy? that is : the clients send MOSDOp msg to read > some objects of a file, the msg includes many read ops(we can define > the first Op as to read the object we wan at this time, and other Ops > is going to do readahead work), these Ops ask OSD to read some objects > ahead and OSD don't reply to those Ops, they only need to reply the > client when got the wanted object. So, at the next time to read the > different objects of that file, it can got data from OSDs' cache,that > will promote read performance. All the readahead work was done > internal OSD cluster. Not right now -- all readahead has to be initiated by the client. Note that in cases where readahead is useful the relative on-disk lookup time isn't going to be that large since it's using 4MB objects. I don't think that in general you'd gain anything by trying to manage the OSD cache from the client anyway! > 2) ceph use osd journal to keep perfect stability, but that decrease > the write performance as we see, can we record just metadata of the > WRITE op in journal write item, but not the whole data buffer,in that > way we can reponse client quickly. If the OSD crashed, we can replay > the journal, but at this time we need to request data from CLIENT, > which increase the complexity. Trying to request data from the client like this would not work out well -- how would the client know when it was safe to drop the data out of memory? What happens if the OSD sends back a success message, then crashes, and the client shuts down or crashes too? The doubled writes can be annoying, but it's really the only safe thing to do. Perhaps we could do something with btrfs and snapshots to avoid using a journal, but I'd have to look into it some more. -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
