1. 02 Jul, 2013 2 commits
  2. 01 Jul, 2013 5 commits
  3. 28 Jun, 2013 7 commits
    • Philipp Reisner's avatar
      drbd: Allow online change of al-stripes and al-stripe-size · d752b269
      Philipp Reisner authored
      Allow to change the AL layout with an resize operation. For that
      the reisze command gets two new fields: al_stripes and al_stripe_size.
      
      In order to make the operation crash save:
      1) Lock out all IO and MD-IO
      2) Write the super block with MDF_PRIMARY_IND clear
      3) write the bitmap to the new location (all zeros, since
         we allow only while connected)
      4) Initialize the new AL-area
      5) Write the super block with the restored MDF_PRIMARY_IND.
      6) Unfreeze all IO
      
      Since the AL-layout has no influence on the protocol, this operation
      needs to be beforemed on both sides of a resource (if intended).
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@linbit.com>
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      d752b269
    • Philipp Reisner's avatar
      e96c9633
    • Philipp Reisner's avatar
      drbd: Ignore the exit code of a fence-peer handler if it returns too late · 28e448bb
      Philipp Reisner authored
      In case the connection was established and lost again before
      the a fence-peer handler returns, ignore the exit code of this
      instance. (And use the exit code of the later started instance)
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@linbit.com>
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      28e448bb
    • Andreas Gruenbacher's avatar
    • Wei Yongjun's avatar
      drbd: fix error return code in drbd_init() · 6110d70b
      Wei Yongjun authored
      Fix to return a negative error code from the error handling
      case instead of 0, as returned elsewhere in this function.
      Signed-off-by: default avatarWei Yongjun <yongjun_wei@trendmicro.com.cn>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@linbit.com>
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      6110d70b
    • Andreas Gruenbacher's avatar
      drbd: Do not sleep inside rcu · 26ea8f92
      Andreas Gruenbacher authored
      Signed-off-by: default avatarAndreas Gruenbacher <agruen@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      26ea8f92
    • Jens Axboe's avatar
      Merge branch 'stable/for-jens-3.10' of... · f35546e0
      Jens Axboe authored
      Merge branch 'stable/for-jens-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen into for-3.11/drivers
      
      Konrad writes:
      
      It has the 'feature-max-indirect-segments' implemented in both backend
      and frontend. The current problem with the backend and frontend is that the
      segment size is limited to 11 pages. It means we can at most squeeze in 44kB per
      request. The ring can hold 32 (next power of two below 36) requests, meaning we
      can do 1.4M of outstanding requests. Nowadays that is not enough.
      
      The problem in the past was addressed in two ways - but neither one went upstream.
      The first solution to this proposed by Justin from Spectralogic was to negotiate
      the segment size.  This means that the ‘struct blkif_sring_entry’ is now a variable size.
      It can expand from 112 bytes (cover 11 pages of data - 44kB) to 1580 bytes
      (256 pages of data - so 1MB). It is a simple extension by just making the array in the
      request expand from 11 to a variable size negotiated. But it had limits: this extension
      still limits the number of segments per request to 255 (as the total number must be
      specified in the request, which only has an 8-bit field for that purpose).
      
      The other solution (from Intel - Ronghui) was to create one extra ring that only has the
      ‘struct blkif_request_segment’ in them. The ‘struct blkif_request’ would be changed to have
      an index in said ‘segment ring’. There is only one segment ring. This means that the size of
      the initial ring is still the same. The requests would point to the segment and enumerate out
      how many of the indexes it wants to use. The limit is of course the size of the segment.
      If one assumes a one-page segment this means we can in one request cover ~4MB.
      
      Those patches were posted as RFC and the author never followed up on the ideas on changing
      it to be a bit more flexible.
      
      There is yet another mechanism that could be employed  (which these patches implement) - and it
      borrows from VirtIO protocol. And that is the ‘indirect descriptors’. This very similar to
      what Intel suggests, but with a twist. The twist is to negotiate how many of these
      'segment' pages (aka indirect descriptor pages) we want to support (in reality we negotiate
      how many entries in the segment we want to cover, and we module the number if it is
      bigger than the segment size).
      
      This means that with the existing 36 slots in the ring (single page) we can cover:
      32 slots * each blkif_request_indirect covers: 512 * 4096 ~= 64M. Since we ample space
      in the blkif_request_indirect to span more than one indirect page, that number (64M)
      can be also multiplied by eight = 512MB.
      
      Roger Pau Monne took the idea and implemented them in these patches. They work
      great and the corner cases (migration between backends with and without this extension)
      work nicely. The backend has a limit right now off how many indirect entries
      it can handle: one indirect page, and at maximum 256 entries (out of 512 - so  50% of the page
      is used). That comes out to 32 slots * 256 entries in a indirect page * 1 indirect page
      per request * 4096 = 32MB.
      
      This is a conservative number that can change in the future. Right now it strikes
      a good balance between giving excellent performance, memory usage in the backend, and
      balancing the needs of many guests.
      
      In the patchset there is also the split of the blkback structure to be per-VBD.
      This means that the spinlock contention we had with many guests trying to do I/O and
      all the blkback threads hitting the same lock has been eliminated.
      
      Also there are bug-fixes to deal with oddly sized sectors, insane amounts on
      th ring, and also a security fix (posted earlier).
      f35546e0
  4. 27 Jun, 2013 15 commits
  5. 25 Jun, 2013 1 commit
  6. 22 Jun, 2013 9 commits
  7. 21 Jun, 2013 1 commit