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-11018 Lustre <p>investigate how async close RPC can improve small file performance for cases like tar -xf</p> <p>we used to have this in the past, but performance impact was rather negative even with a single thread. it makes sense to evaluate the idea again with multislot feature.</p> <p>ideally, open/close(no OST objects) rate should be very close to mknod rate</p> <p> </p> LU-11018

async close RPC

Improvement Minor Open Unresolved Alex Zhuravlev Alex Zhuravlev SFIO Mon, 14 May 2018 10:13:50 +0000 Tue, 15 May 2018 01:34:28 +0000 0 4 <p>One of the bigger concerns with this that I am having it the dreaded write/exec EBUSY stuff.<br/> Imagine that you are sending a close that's async and signal another process that your write is done and they try to execute things...</p> <p>One of the potential workarounds probably lies in the open locks. I know they are slow now, but I think we should enable them at all times and to make them fast we just need to change the blocking logic to have MDS_CLOSE RPC to include the open lock to be cancelled in the same rpc.</p> <p>That means any regular open/close loop would operate at hte speed of open - ie single RPC, and the close is just a local even until a conflicting open/unlink/whatever - that one would send a blocking RPC (but nowadays every open returns a lock - so no change in behavior here) and the response would be close RPC that also happens to pack the lock cancel in it (cannot do it ELC style, though).</p> Related LU-10938 Development Rank 1|hzzx4v: Rank (Obsolete) 9223372036854775807