1. 13 Jun, 2016 3 commits
    • Lars Ellenberg's avatar
      drbd: allow larger max_discard_sectors · 505675f9
      Lars Ellenberg authored
      Make sure we have at least 67 (> AL_UPDATES_PER_TRANSACTION)
      al-extents available, and allow up to half of that to be
      discarded in one bio.
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
    • Lars Ellenberg's avatar
      drbd: when receiving P_TRIM, zero-out partial unaligned chunks · dd4f699d
      Lars Ellenberg authored
      We can avoid spurious data divergence caused by partially-ignored
      discards on certain backends with discard_zeroes_data=0, if we
      translate partial unaligned discard requests into explicit zero-out.
      The relevant use case is LVM/DM thin.
      If on different nodes, DRBD is backed by devices with differing
      discard characteristics, discards may lead to data divergence
      (old data or garbage left over on one backend, zeroes due to
      unmapped areas on the other backend). Online verify would now
      potentially report tons of spurious differences.
      While probably harmless for most use cases (fstrim on a file system),
      DRBD cannot have that, it would violate our promise to upper layers
      that our data instances on the nodes are identical.
      To be correct and play safe (make sure data is identical on both copies),
      we would have to disable discard support, if our local backend (on a
      Primary) does not support "discard_zeroes_data=true".
      We'd also have to translate discards to explicit zero-out on the
      receiving (typically: Secondary) side, unless the receiving side
      supports "discard_zeroes_data=true".
      Which both would allocate those blocks, instead of unmapping them,
      in contrast with expectations.
      LVM/DM thin does set discard_zeroes_data=0,
      because it silently ignores discards to partial chunks.
      We can work around this by checking the alignment first.
      For unaligned (wrt. alignment and granularity) or too small discards,
      we zero-out the initial (and/or) trailing unaligned partial chunks,
      but discard all the aligned full chunks.
      At least for LVM/DM thin, the result is effectively "discard_zeroes_data=1".
      Arguably it should behave this way internally, by default,
      and we'll try to make that happen.
      But our workaround is still valid for already deployed setups,
      and for other devices that may behave this way.
      Setting discard-zeroes-if-aligned=yes will allow DRBD to use
      discards, and to announce discard_zeroes_data=true, even on
      backends that announce discard_zeroes_data=false.
      Setting discard-zeroes-if-aligned=no will cause DRBD to always
      fall-back to zero-out on the receiving side, and to not even
      announce discard capabilities on the Primary, if the respective
      backend announces discard_zeroes_data=false.
      We used to ignore the discard_zeroes_data setting completely.
      To not break established and expected behaviour, and suddenly
      cause fstrim on thin-provisioned LVs to run out-of-space,
      instead of freeing up space, the default value is "yes".
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
    • Philipp Reisner's avatar
      drbd: Introduce new disk config option rs-discard-granularity · a5ca66c4
      Philipp Reisner authored
      As long as the value is 0 the feature is disabled. With setting
      it to a positive value, DRBD limits and aligns its resync requests
      to the rs-discard-granularity setting. If the sync source detects
      all zeros in such a block, the resync target discards the range
      on disk.
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
  2. 10 Jul, 2014 2 commits
    • Philipp Reisner's avatar
      drbd: New net configuration option socket-check-timeout · 5d0b17f1
      Philipp Reisner authored
      In setups involving a DRBD-proxy and connections that experience a lot of
      buffer-bloat it might be necessary to set ping-timeout to an
      unusual high value. By default DRBD uses the same value to wait if a newly
      established TCP-connection is stable. Since the DRBD-proxy is usually located
      in the same data center such a long wait time may hinder DRBD's connect process.
      In such setups socket-check-timeout should be set to
      at least to the round trip time between DRBD and DRBD-proxy. I.e. in most
      cases to 1.
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
    • Lars Ellenberg's avatar
      drbd: implement csums-after-crash-only · aaaba345
      Lars Ellenberg authored
      Checksum based resync trades CPU cycles for network bandwidth,
      in situations where we expect much of the to-be-resynced blocks
      to be actually identical on both sides already.
      In a "network hickup" scenario, it won't help:
      all to-be-resynced blocks will typically be different.
      The use case is for the resync of *potentially* different blocks
      after crash recovery -- the crash recovery had marked larger areas
      (those covered by the activity log) as need-to-be-resynced,
      just in case. Most of those blocks will be identical.
      This option makes it possible to configure checksum based resync,
      but only actually use it for the first resync after primary crash.
      Signed-off-by: default avatarPhilipp Reisner <philipp.reisner@linbit.com>
      Signed-off-by: default avatarLars Ellenberg <lars.ellenberg@linbit.com>
  3. 28 Jun, 2013 1 commit
  4. 22 Mar, 2013 1 commit
  5. 08 Nov, 2012 17 commits
  6. 09 May, 2012 2 commits
  7. 14 Oct, 2011 2 commits
  8. 30 Jun, 2011 1 commit
  9. 31 Mar, 2011 1 commit
  10. 10 Mar, 2011 2 commits
  11. 14 Oct, 2010 4 commits
  12. 17 May, 2010 1 commit
  13. 04 Nov, 2009 1 commit
  14. 01 Oct, 2009 1 commit