https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-7319 Lustre <p>in some cases it would be useful to continue updates processing even if some of updates fail. for example, when MDT synchronizes with OST it needs to send a batch of attr_set/destroy updates, up to few thousands in a single RPC. it doesn't make sense to send another batch if some of destroy failed (say, with -ENOENT).</p> LU-7319

OUT: continue updates processing upon an error

Improvement Minor Open Unresolved Alex Zhuravlev Alex Zhuravlev Tue, 20 Oct 2015 14:01:03 +0000 Thu, 23 Dec 2021 12:07:34 +0000 Lustre 2.8.0 0 1 <p>the major problem here is how to reconstruct. say, we've got an RPC with 3 transactions (1 update in each for simplicity). we've executed 2 transactions, then crashed. ideally, during recovery we'd like to skip those 2 transactions, execute missing one and reconstruct the reply with appropriate result codes. but we don't have enough space to store all codes in a last_rcvd's slot. I think there are obvious options here:<br/> 1) OUT to store result codes in an own object <br/> 2) stop execution upon an error and store XID/batchid in a last_rcvd's slot &#8211; essentially never proceed execution upon an error and force the initiator to resubmit remaining part. this in turn can result in a silly sequence of huge requests returning an error after every executed update (say, MDT wants to synchronize OST object destroys, but they have been destroyed already).<br/> 3) apply this logic only to idempotent updates, so we're able to execute again instead of reconstruction</p> Blocker LU-4215 Related LU-12310 Development Rank 1|hzxqw7: Rank (Obsolete) 9223372036854775807