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

use the dcache properly with .lustre/fid

Details

    • Bug
    • Resolution: Unresolved
    • Minor
    • Upstream
    • None
    • None
    • 3
    • 9223372036854775807

    Description

      While addressing several bugs for how Lustre handles the dcache a bug was exposed with sanity test 233. In the testing with newer kernels the following was seen:

      VFS: Lookup of '[0x200000002:0x1:0x0]' in lustre lustre would have caused loop

      In older kernels it is an outright crash of the node. After some debugging it was discovered why. If a name in .lustre/fid refers to a directory, then that directory will (could) have 2 names in the dcache - the name in .lustre/fid, and the "real" name. The dcache does not permit this. You cannot have two dentries pointing the the same directory inode. Multiple hard links to directories are forbidden. Currently lustre attempts to break this rule by spinning its own dcache routines but that does not guarantee in the future that some core dcache functionality will change that breaks lustre. Due to the having multiple hard links you can form loops like reported above or if some core dcache functionality does an assert of dancestor() that will crash the node.  It could even be possible that in the future the dcache core code might even prune its cache of broken dentries.

      Attachments

        Issue Links

          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-5008 bad negative dentry caching in .lustre/fid

          • Major - Major loss of function.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. LU-8585 All Lustre test suites should pass with subdirectory mount

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Open

          Improvement - An improvement or enhancement to an existing feature or task. LU-9629 lfs migrate does not work as a non-root user

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Question/Request - A product question or request LU-11970 Using changelog reader causes fid2path process to lockup in kernel space

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved
          is related to

          Bug - A problem which impairs or prevents the functions of the product. LU-9868 dcache/namei fixes for lustre

          • Major - Major loss of function.
          • Open

          Activity

            [LU-11501] use the dcache properly with .lustre/fid
            gerrit Gerrit Updater added a comment -

            "James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/44846
            Subject: LU-11501 llite: use d_real for directories in fid cache.
            Project: fs/lustre-release
            Branch: master
            Current Patch Set: 1
            Commit: 26e52756fe807e23d1c76ad5d257ae1f0c81e989

            gerrit Gerrit Updater added a comment - "James Simmons <jsimmons@infradead.org>" uploaded a new patch: https://review.whamcloud.com/44846 Subject: LU-11501 llite: use d_real for directories in fid cache. Project: fs/lustre-release Branch: master Current Patch Set: 1 Commit: 26e52756fe807e23d1c76ad5d257ae1f0c81e989
            simmonsja James A Simmons added a comment -

            Yes its a longer term project. Currently the way lustre handles .lustre/fid in relation to the dcache is starting to show up with tickets like LU-9735. I'm working around the issues but in the future we can expect more breakage. Will look into other solutions

            simmonsja James A Simmons added a comment - Yes its a longer term project. Currently the way lustre handles .lustre/fid in relation to the dcache is starting to show up with tickets like LU-9735 . I'm working around the issues but in the future we can expect more breakage. Will look into other solutions
            pjones Peter Jones added a comment -

            James

            Do I understand correctly that this is a longer-term task relating to the upstream kernel work?

            Peter

            pjones Peter Jones added a comment - James Do I understand correctly that this is a longer-term task relating to the upstream kernel work? Peter

            People

              simmonsja James A Simmons
              simmonsja James A Simmons
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated: