1. 06 May, 2010 8 commits
    • Mark Fasheh's avatar
      ocfs2: increase the default size of local alloc windows · 6b82021b
      Mark Fasheh authored
      I have observed that the current size of 8M gives us pretty poor
      fragmentation on multi-threaded workloads which do lots of writes.
      
      Generally, I can increase the size of local alloc windows and observe a
      marked decrease in fragmentation, even up and beyond window sizes of 512
      megabytes. This makes sense for a couple reasons - larger local alloc means
      more room for reservation windows. On multi-node workloads the larger local
      alloc helps as well because we don't have to do window slides as often.
      
      Also, I removed the OCFS2_DEFAULT_LOCAL_ALLOC_SIZE constant as it is no
      longer used and the comment above it was out of date.
      
      To test fragmentation, I used a workload which launched 4 threads that did
      4k writes into a series of about 140 alternating files.
      
      With resv_level=2, and a 4k/4k file system I observed the following average
      fragmentation for various localalloc= parameters:
      
      localalloc=	avg. fragmentation
      	8		48
      	32		16
      	64		10
      	120		7
      
      On larger cluster sizes, the difference is more dramatic.
      
      The new default size top out at 256M, which we'll only get for cluster
      sizes of 32K and above.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      6b82021b
    • Mark Fasheh's avatar
      ocfs2: clean up localalloc mount option size parsing · 73c8a800
      Mark Fasheh authored
      This patch pulls the local alloc sizing code into localalloc.c and provides
      a callout to it from ocfs2_fill_super(). Behavior is essentially unchanged
      except that I correctly calculate the maximum local alloc size. The old code
      in ocfs2_parse_options() calculated the max size as:
      
      ocfs2_local_alloc_size(sb) * 8
      
      which is correct, in bits. Unfortunately though the option passed in is in
      megabytes. Ultimately, this bug made no real difference - the shrink code
      would catch a too-large size and bring it down to something reasonable.
      Still, it's less than efficient as-is.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      73c8a800
    • Mark Fasheh's avatar
      ocfs2: remove ocfs2_local_alloc_in_range() · a57c8fd2
      Mark Fasheh authored
      Inodes are always allocated from the global bitmap now so we don't need this
      any more. Also, the existing implementation bounces reservations around
      needlessly.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      a57c8fd2
    • Mark Fasheh's avatar
      ocfs2: allocate btree internal block groups from the global bitmap · 33d5d380
      Mark Fasheh authored
      Otherwise, the need for a very large contiguous allocation tends to
      wreak havoc on many inode allocation reservations on the local alloc, thus
      ruining any chances for contiguousness.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      33d5d380
    • Mark Fasheh's avatar
      ocfs2: use allocation reservations for directory data · e3b4a97d
      Mark Fasheh authored
      Use the reservations system for unindexed dir tree allocations. We don't
      bother with the indexed tree as reads from it are mostly random anyway.
      Directory reservations are marked seperately, to allow the reservations code
      a chance to optimize their window sizes. This patch allocates only 8 bits
      for directory windows as they generally are not expected to grow as quickly
      as file data. Future improvements to dir window sizing can trivially be
      made.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      e3b4a97d
    • Mark Fasheh's avatar
      ocfs2: use allocation reservations during file write · 4fe370af
      Mark Fasheh authored
      Add a per-inode reservations structure and pass it through to the
      reservations code.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      4fe370af
    • Mark Fasheh's avatar
      ocfs2: allocation reservations · d02f00cc
      Mark Fasheh authored
      This patch improves Ocfs2 allocation policy by allowing an inode to
      reserve a portion of the local alloc bitmap for itself. The reserved
      portion (allocation window) is advisory in that other allocation
      windows might steal it if the local alloc bitmap becomes
      full. Otherwise, the reservations are honored and guaranteed to be
      free. When the local alloc window is moved to a different portion of
      the bitmap, existing reservations are discarded.
      
      Reservation windows are represented internally by a red-black
      tree. Within that tree, each node represents the reservation window of
      one inode. An LRU of active reservations is also maintained. When new
      data is written, we allocate it from the inodes window. When all bits
      in a window are exhausted, we allocate a new one as close to the
      previous one as possible. Should we not find free space, an existing
      reservation is pulled off the LRU and cannibalized.
      Signed-off-by: default avatarMark Fasheh <mfasheh@suse.com>
      d02f00cc
    • Joel Becker's avatar
      ocfs2: Make ocfs2_journal_dirty() void. · ec20cec7
      Joel Becker authored
      jbd[2]_journal_dirty_metadata() only returns 0.  It's been returning 0
      since before the kernel moved to git.  There is no point in checking
      this error.
      
      ocfs2_journal_dirty() has been faithfully returning the status since the
      beginning.  All over ocfs2, we have blocks of code checking this can't
      fail status.  In the past few years, we've tried to avoid adding these
      checks, because they are pointless.  But anyone who looks at our code
      assumes they are needed.
      
      Finally, ocfs2_journal_dirty() is made a void function.  All error
      checking is removed from other files.  We'll BUG_ON() the status of
      jbd2_journal_dirty_metadata() just in case they change it someday.  They
      won't.
      Signed-off-by: default avatarJoel Becker <joel.becker@oracle.com>
      ec20cec7
  2. 24 Mar, 2010 1 commit
    • 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
  3. 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
  4. 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
  5. 17 Mar, 2010 4 commits
  6. 15 Mar, 2010 21 commits
  7. 14 Mar, 2010 3 commits