1. 12 Jul, 2017 3 commits
  2. 11 Jul, 2017 7 commits
    • Christian Mohrbacher's avatar
      Merge branch 'v6-modsync-errors' into 'v6' · 132fe3f9
      Christian Mohrbacher authored
      V6 modsync errors
      
      See merge request !224
      132fe3f9
    • Phoebe Buckheister's avatar
      meta: lock created file in MkFileWithPatternMsg · 1c316f79
      Phoebe Buckheister authored
      lock the newly created file as required by the resyncer locking
      protocol. effectively the lock is not necessary because the parent
      directory is already locked and modsync cannot pick up the file before
      we return Success, but it is better to follow the protocol here than it
      is to optimize.
      
      (cherry picked from commit 3a98b0c532780ef54e7a043cab59cf795f4cfa50)
      1c316f79
    • Phoebe Buckheister's avatar
      meta: correctly lock items in MovingFileInsertMsg · 770e1a73
      Phoebe Buckheister authored
       * toDir always resides on the local node, so previously we would never
         have locked anything at all. check for locally generates requests
         instead.
       * don't lazily lock the new file and the unlinked file to avoid
         deadlocks
       * also lock the parent/name of the new dentry to comply with the
         resyncer protocol
      
      (cherry picked from commit ec78409c4acf95814cafcd5097dda783f9308c70)
      770e1a73
    • Phoebe Buckheister's avatar
      meta: don't send UpdateDirParent from secondary during move · 2a0ab2fb
      Phoebe Buckheister authored
      not only is this unnecessary work (the primary has already sent the
      message), it may also race with a starting resync and cause a deadlock
      when the UpdateDirParent message is sent back to the primary.
      
      (cherry picked from commit 08efde057b58ba6e3de2c651757e78967857a23b)
      2a0ab2fb
    • Phoebe Buckheister's avatar
      meta: correctly lock items in MovingDirInsertMsg · 43209ada
      Phoebe Buckheister authored
       * toDir always resides on the local node, so previously we would never
         have locked anything at all. check for locally generates requests
         instead.
       * also lock the parent/name of the new dentry to comply with the
         resyncer protocol
      
      (cherry picked from commit b40c93c1fa1bb3ca44644c197c22b3936cc8553e)
      43209ada
    • Phoebe Buckheister's avatar
      meta: lock file inode during hardlink · 12ccc042
      Phoebe Buckheister authored
      hardlinking modifies the inode link count (among other things) and will
      thus modsync the inode during resync, so it must be locked.
      
      (cherry picked from commit dc0ee14ed596553bae1d0c3e9410d6cc7a4bee91)
      12ccc042
    • Phoebe Buckheister's avatar
      meta: commit resync changes before sending responses · 6ae44283
      Phoebe Buckheister authored
      usually we may commit resync changes after the response was sent, but
      this is *not* safe for messages that communicate with other servers
      during processing (eg MkDir). in such a case a response may be sent for
      the "inner" request to the "outer" request before the changeset is
      applied, causing the "outer" request to unlock its state before it is
      safe to do so.
      
      (cherry picked from commit ab1b2a032350e525b88ee48501e05ea83de47225)
      6ae44283
  3. 06 Jul, 2017 1 commit
  4. 05 Jul, 2017 3 commits
    • Phoebe Buckheister's avatar
      meta: during rename, lock target name if fromDir != toDir · d3ba2440
      Phoebe Buckheister authored
      the locking code correctly enforces directory lock ordering using the
      order on (fromDirID, forWrite). it also correctly enforces lock
      ordering on parent/name combinations on (parentID, name).
      
      if oldName and newName are the same though it does not correctly lock
      (toDirID, newName).
      
      (cherry picked from commit a8e6b9d0e217437812fe6cd4624382d97808d768)
      d3ba2440
    • Phoebe Buckheister's avatar
      meta: lock inode/dentry hash dirs during resync · 93d2a1ff
      Phoebe Buckheister authored
      mkdir() and rmdir() during resync can cause races between bulk sync and
      mod sync that can lead to failed resyncs or even data loss.
      
      if a client runs mkdir() that creates an inode in inodes/$L1/$L2 after
      bulk sync for inodes/$L1/$L2 has synced all inodes, but before (or
      while) bulk sync is removing all inodes it has not transferred itself,
      the new inode may be erroneously deleted. if a client runs rmdir()
      instead, the deleted inode may cause a resync failure when bulk sync
      tries to remove a file that is no longer present.
      
      (cherry picked from commit a0c307c513a7697be03ddd0c203c6e612a936053)
      93d2a1ff
    • Phoebe Buckheister's avatar
      meta: lock overwritten file during rename in same dir · 0e22941a
      Phoebe Buckheister authored
      if a file is overwritten by a rename it must be locked before it is
      actually touched in any way. without the lock concurrent operations on
      the same inode (like close, setxattr, or others) can race with the
      unlink. this race is normally inconsequential, but during mod resync it
      allows an inlined inode to be deleted before all "file changed" modsync
      events have been processed, causing the resync to resync to fail with
      modsync errors.
      
      (cherry picked from commit 2e4d732ca2a343844fbf76cdec94107e040a406a)
      0e22941a
  5. 04 Jul, 2017 3 commits
  6. 29 Jun, 2017 1 commit
    • Phoebe Buckheister's avatar
      fsck/meta: don't start resync immediatly after first repair action · 89a75bc0
      Phoebe Buckheister authored
      many repair actions may follow after the first has executed, but repair
      actions are not modsynced to the secondary while resync is running. set
      the secondary of a group to BAD once a repair action is attempted on
      the primary, and set all secondaries with repairs to NEEDS-RESYNC when
      all repair actions have completed.
      
      see #626
      
      (cherry picked from commit 4ae6ba4c55db22c5cc5ce7a6792e12bd67a29b69)
      89a75bc0
  7. 27 Jun, 2017 2 commits
  8. 22 Jun, 2017 2 commits
  9. 19 Jun, 2017 3 commits
  10. 14 Jun, 2017 5 commits
  11. 08 Jun, 2017 6 commits
  12. 07 Jun, 2017 4 commits