[LU-11018] async close RPC

• Type: Improvement
• Resolution: Unresolved
• Priority: Minor
• Labels: SFIO
• Assignee: Alex Zhuravlev
• Reporter: Alex Zhuravlev

Description

investigate how async close RPC can improve small file performance for cases like tar -xf

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.

ideally, open/close(no OST objects) rate should be very close to mknod rate

 

Issue Links

• is related to: LU-10938 Metadata writeback cache support

Comments

[Oleg Drokin]

One of the bigger concerns with this that I am having it the dreaded write/exec EBUSY stuff.
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...

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.

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).