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

       

      Attachments

        Issue Links

          Activity

            [LU-11018] async close RPC
            green Oleg Drokin added a comment -

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

            green Oleg Drokin added a comment - 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).

            People

              bzzz Alex Zhuravlev
              bzzz Alex Zhuravlev
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated: