It's reasonable enough. actually, I expected the client to have just? thousands of "PG-to-OSDs" mappings. Nevertheless, it’s so heavy that the client calculates location on demand, right? if the client with the outdated map sends a request to the wrong OSD, then does the OSD handle it somehow through redirection or something? Lastly, not only CRUSH map but also other factors like storage usage are considered when doing CRUSH? because it seems that the target OSD set isn’t deterministic given only it. 2024년 1월 25일 (목) 오후 4:42, Janne Johansson <icepic.dz@xxxxxxxxx>님이 작성: > > Den tors 25 jan. 2024 kl 03:05 skrev Henry lol <pub.virtualization@xxxxxxxxx>: > > > > Do you mean object location (osds) is initially calculated only using its > > name and crushmap, > > and then the result is reprocessed with the map of the PGs? > > > > and I'm still skeptical about computation on the client-side. > > is it possible to obtain object location without computation on the client > > because ceph-mon already updates that information to PG map? > > The client should not need to contact the mon for each object access > and every client can't have a complete list of millions of objects in > the cluster, so it does client-side computations. > > The mon connection will more or less only require new updates if/when > OSDs change weight or goes in/out. This way, clients can run on > "autopilot" even if all mons are down, as long as OSD states don't > change. > > -- > May the most significant bit of your life be positive. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |