[LU-10448] policy to pick a primary for mirrored write Created: 03/Jan/18  Updated: 02/Mar/18  Resolved: 14/Feb/18

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.11.0
Fix Version/s: Lustre 2.11.0

Type: Improvement Priority: Major
Reporter: Zhenyu Xu Assignee: Zhenyu Xu
Resolution: Fixed Votes: 0
Labels: FLR2

Issue Links:
Related
is related to LU-9771 FLR1: Landing tickets for File Level ... Resolved
is related to LU-10158 FLR: Define a replica choosing policy... Open
is related to LU-10670 sanity-flr test 43 timeout Resolved
Rank (Obsolete): 9223372036854775807

 Description   

For a mirrored file, when it is written at the first time, the policy to pick a replica as primary is primitive, either it just chooses the first replica or a random one. A policy function should be defined for replica choosing. At least it should avoid the replicas with unavailable OSTs.



 Comments   
Comment by Andreas Dilger [ 03/Jan/18 ]

For 2.11 at a very minimum it should avoid selecting replicas that are not available. Otherwise FLR is mostly not useful in case of failures?

Comment by Gerrit Updater [ 04/Jan/18 ]

Bobi Jam (bobijam@hotmail.com) uploaded a new patch: https://review.whamcloud.com/30711
Subject: LU-10448 lod: pick primary mirror for write
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: dc578c783c1aa74c2656e6cb481e3b69bb01c18a

Comment by Jinshan Xiong (Inactive) [ 05/Jan/18 ]

Andreas - this is about the policy for picking a replica for write. FLR is still useful for read w/o this feature.

Comment by Andreas Dilger [ 19/Jan/18 ]

This is needed for 2.11 so that writes don't pick unavailable replicas.

Comment by Gerrit Updater [ 14/Feb/18 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/30711/
Subject: LU-10448 lod: pick primary mirror for write
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 6b373937774d0b3736d02b260be9a81c7eff5351

Comment by Minh Diep [ 14/Feb/18 ]

Landed for 2.11

Generated at Sat Feb 10 02:35:11 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.