Details
-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
-
None
-
9223372036854775807
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
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).