Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-8860

lock callback errors after client umount

    XMLWordPrintable

Details

    • Bug
    • Resolution: Won't Fix
    • Minor
    • None
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      During performance testing I've noticed error messages from AST callbacks like this:

      LustreError: 12408:0:(client.c:1164:ptlrpc_import_delay_req()) @@@ IMP_CLOSED   req@ffff880051aa6520 x1551685286400384/t0(0) o104->lustre-MDT0000@0@lo:15/16 lens 296/224 e 0 to 0 dl 0 ref 1 fl Rpc:/0/ffffffff rc 0/-1
      LustreError: 12408:0:(client.c:1164:ptlrpc_import_delay_req()) Skipped 2 previous similar messages
      LustreError: 12408:0:(ldlm_lockd.c:687:ldlm_handle_ast_error()) ### client (nid 0@lo) failed to reply to blocking AST (req@ffff880051aa6520 x1551685286400384 status 0 rc -5), evict it ns: mdt-lustre-MDT0000_UUID
      

      This happens if client performed some tests actively and was remounted. The reason of this is the old disconnected export which is not yet fully finished while new connection is established already. As result there are locks from that old export and new operations might conflict with some of them, causing blocking AST attempt. When AST request is prepared the ptlrpc_import_delay_req() find its import is in CLOSED state and return -EIO error. Then ldlm_handle_ast_error() consider this as an error and evict old export which is disconnected already.

      I think that makes a little sense to perform all these actions, better to recognize that export is failed/disconnected when we found the lock and don't consider it as blocking lock at all.

      Attachments

        Issue Links

          Activity

            People

              tappro Mikhail Pershin
              tappro Mikhail Pershin
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: