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

mdt: remote same-directory rename does not lock the target name

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Medium Medium
    • None
    • None
    • None
    • 3
    • 9223372036854775807

      A rename within one directory locks the target name's PDO bucket only
      when the directory is local to the serving MDT (mdt_lock_two_dirs(),
      the !mdt_object_remote() check). A same-directory rename is served on
      the MDT of the file at the target name when one exists, so when that
      file lives on another MDT than the directory, the rename holds the
      directory's CW lock and the source name's bucket only. The target
      name can then change between the rename's lookup of it and its child
      locks, and nothing looks it up again: mdd_rename() deletes the target
      entry by name.

      Since LU-15526 (7270e16fcb, 2.16.0) a PW lock on a remote parent is a
      per-name PDO lock; before it, it was a whole-directory lock that
      covered the target name. From then on an unlink and re-create of the
      target name can change it in the window. Since LU-17427 (8dbf049479,
      2.17.0) the BFL is taken after the child locks, so another rename
      onto the same name can too.

      Effect, two clients renaming different files onto one name:

      • If the file at the target name has no other link, the second rename
        fails with ENOENT and changes nothing. POSIX requires it to succeed,
        so an application replacing a file atomically (write temp, rename
        over) sees an unexpected error.
      • If that file has another hard link, the second rename deletes the
        entry that now names the first rename's file and inserts its own.
        The first rename's file is left with nlink 1 and no name (an orphan,
        visible to LFSCK only), and the file the second rename looked up is
        destroyed while its other hard link still names it. Both renames
        return 0.

      Reproduced on master with a fail point holding the second rename after
      its target lookup (directory on MDT0, files on MDT1, A/dst hard linked
      as A/keep; mv A/a A/dst and mv A/b A/dst from two mounts): A/dst names
      the second file, A/keep no longer resolves, and the first file is an
      orphan. The unlink/re-create route follows from the source and is not
      reproduced.

      Fix: lock the target name's bucket for a remote directory too, in hash
      order as LU-15285 does for a local one. Patch, with regression test
      sanityn 81j: https://review.whamcloud.com/c/fs/lustre-release/+/69434

      The parallel cross-MDT file rename change (LU-20831,
      https://review.whamcloud.com/c/fs/lustre-release/+/69203) widens the
      window further by removing the BFL from these renames, and is stacked
      on top of the fix.

            wc-triage WC Triage
            paf0186 Patrick Farrell
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: