On Thu, 25 May 2017, qi Shi wrote: > When the ceph client reads a very hot little file (less than 4M). The > application scenario is live video. A single disk may have a > bottleneck. The ceph client only reads the primary pg of osd. But this > is the implementation of the serial. My suggestion is to change the > primary read to random read three replication, or change to read 3 > replications at the same time, so to improve the reading efficiency. In the general case, reading from the primary is the best policy because it localizes the caches (for example, for a given object A, it will only be cached in 1 place instead of 3, thereby allowing 3x as much data to be fit into cache). The exception, of course, is very hot objects that saturate a single OSD's CPU or network (not disk--they're generally cached!), but these are rare. There is code in librados that allows a client to send a (read) request to a random replica, but the client has to know when to do that. More importantly, there is not test coverage for it, so we don't know if it is reliable/stable (particularly with recovery). There were known bugs that Sam was looking at a year or so ago but I don't recall if he thought he fixed them (I think no). But either way, it's not tested, so should not be considered reliable. 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