1. 24 Mar, 2010 3 commits
    • Tristan Ye's avatar
      Ocfs2: Handle deletion of reflinked oprhan inodes correctly. · b54c2ca4
      Tristan Ye authored
      The rule is that all inodes in the orphan dir have ORPHANED_FL,
      otherwise we treated it as an ERROR.  This rule works well except
      for some rare cases of reflink operation:
      
      http://oss.oracle.com/bugzilla/show_bug.cgi?id=1215
      
      The problem is caused by how reflink and our orphan_scan thread
      interact.
      
       * The orphan scan pulls the orphans into a queue first, then runs the
         queue at a later time.  We only hold the orphan_dir's lock
         during scanning.
      
       * Reflink create a oprhaned target in orphan_dir as its first step.
         It removes the target and clears the flag as the final step.
         These two steps take the orphan_dir's lock, but it is not held for
         the duration.
      
      Based on the above semantics, a reflink inode can be moved out of the
      orphan dir and have its ORPHANED_FL cleared before the queue of orphans
      is run.  This leads to a ERROR in ocfs2_query_wipde_inode().
      
      This patch teaches ocfs2_query_wipe_inode() to detect previously
      orphaned reflink targets.  If a reflink fails or a crash occurs during
      the relfink operation, the inode will retain ORPHANED_FL and will be
      properly wiped.
      Signed-off-by: default avatarTristan Ye <tristan.ye@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      b54c2ca4
    • Tristan Ye's avatar
      Ocfs2: Journaling i_flags and i_orphaned_slot when adding inode to orphan dir. · 3939fda4
      Tristan Ye authored
      Currently, some callers were missing to journal the dirty inode after
      adding it to orphan dir.
      
      Now we're going to journal such modifications within the ocfs2_orphan_add()
      itself, It's safe to do so, though some existing caller may duplicate this,
      and it makes the logic look more straightforward anyway.
      Signed-off-by: default avatarTristan Ye <tristan.ye@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      3939fda4
    • Mark Fasheh's avatar
      ocfs2: Clear undo bits when local alloc is freed · b4414eea
      Mark Fasheh authored
      When the local alloc file changes windows, unused bits are freed back to the
      global bitmap. By defnition, those bits can not be in use by any file. Also,
      the local alloc will never have been able to allocate those bits if they
      were part of a previous truncate. Therefore it makes sense that we should
      clear unused local alloc bits in the undo buffer so that they can be used
      immediatly.
      
      [ Modified to call it ocfs2_release_clusters() -- Joel ]
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      b4414eea
  2. 19 Mar, 2010 2 commits
    • Tao Ma's avatar
      ocfs2: Init meta_ac properly in ocfs2_create_empty_xattr_block. · b2317968
      Tao Ma authored
      You can't store a pointer that you haven't filled in yet and expect it
      to work.
      Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      b2317968
    • Tao Ma's avatar
      ocfs2: Fix the update of name_offset when removing xattrs · dfe4d3d6
      Tao Ma authored
      When replacing a xattr's value, in some case we wipe its name/value
      first and then re-add it. The wipe is done by
      ocfs2_xa_block_wipe_namevalue() when the xattr is in the inode or
      block. We currently adjust name_offset for all the entries which have
      (offset < name_offset). This does not adjust the entrie we're replacing.
      Since we are replacing the entry, we don't adjust the total entry count.
      When we calculate a new namevalue location, we trust the entries
      now-wrong offset in ocfs2_xa_get_free_start().  The solution is to
      also adjust the name_offset for the replaced entry, allowing
      ocfs2_xa_get_free_start() to calculate the new namevalue location
      correctly.
      
      The following script can trigger a kernel panic easily.
      
      echo 'y'|mkfs.ocfs2 --fs-features=local,xattr -b 4K $DEVICE
      mount -t ocfs2 $DEVICE $MNT_DIR
      FILE=$MNT_DIR/$RANDOM
      for((i=0;i<76;i++))
      do
      string_76="a$string_76"
      done
      string_78="aa$string_76"
      string_82="aaaa$string_78"
      
      touch $FILE
      setfattr -n 'user.test1234567890' -v $string_76 $FILE
      setfattr -n 'user.test1234567890' -v $string_78 $FILE
      setfattr -n 'user.test1234567890' -v $string_82 $FILE
      Signed-off-by: default avatarTao Ma <tao.ma@oracle.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      dfe4d3d6
  3. 18 Mar, 2010 1 commit
    • Mark Fasheh's avatar
      ocfs2: Always try for maximum bits with new local alloc windows · b22b63eb
      Mark Fasheh authored
      What we were doing before was to ask for the current window size as the
      maximum allocation. This had the effect of limiting the amount of allocation
      we could get for the local alloc during times when the window size was
      shrunk due to fragmentation. In some cases, that could actually *increase*
      fragmentation by artificially limiting the number of bits we can accept. So
      while we still want to ask for a minimum number of bits equal to window
      size, there is no reason why we should limit the number of bits the local
      alloc should accept. Hence always allow the maximum number of local alloc
      bits.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      b22b63eb
  4. 17 Mar, 2010 4 commits
  5. 15 Mar, 2010 21 commits
  6. 14 Mar, 2010 9 commits